On 8/30/19 3:59 AM, dirdi wrote:
> Do not bother!
- "bother!"
+ "worry!"
Sorry @Keith, English is only a second language to me and sometimes I
mix-up idioms. You all were very helpful and I learned a lot so far. I
just feel a bit dumb right now =/
--
Best regards
dirdi
On 8/30/19 3:42 PM, David Raymond wrote:
> Sorry if my mind is working slowly today, but why are those showing up as a
> difference when they're exactly the same line?
>
>
> The only difference between both runs:
>> $ diff run1 run2
>> 1260d1259
>> < INSERT INTO space_used
>> VALUES('idx_words1
Sorry if my mind is working slowly today, but why are those showing up as a
difference when they're exactly the same line?
The only difference between both runs:
> $ diff run1 run2
> 1260d1259
> < INSERT INTO space_used
> VALUES('idx_words1','words',1,0,551407,550067,3,3826907,0,0,7,6,1341,0,58
On 8/30/19 3:34 AM, Keith Medcalf wrote:
> Fascinating again, because the code is identical. The p1 difference in the
> OpenWrite/IdxInsert/IdxDelete opcodes is just the "file handle" that happens
> to be being used and doesn't have any real significance (at least I don't
> think it does). The
Stairway to Heaven says a
lot about anticipated traffic volume.
>-Original Message-
>From: sqlite-users [mailto:sqlite-users-
>boun...@mailinglists.sqlite.org] On Behalf Of dirdi
>Sent: Thursday, 29 August, 2019 15:10
>To: sqlite-users@mailinglists.sqlite.org
>Subject: Re:
On 8/29/19 9:19 PM, Keith Medcalf wrote:
> Fascinating ... because the optimal query plan would be to do a table scan of
> tbl1 and then dip into tbl2 for each row to get the update value. The only
> meaningful index then would be on tbl2(int) (that is idx3) since an index
> will be unhelpful f
On 8/29/19 9:35 PM, Simon Slavin wrote:
> On 29 Aug 2019, at 8:12pm, dirdi wrote:
>
>> The only difference between both runs:
>
> Well, that's nothing. I see no reason for the massive change in timing from
> what you posted. But someone else might.
Well the quoted line was shifted to output'
On 29 Aug 2019, at 8:12pm, dirdi wrote:
> The only difference between both runs:
Well, that's nothing. I see no reason for the massive change in timing from
what you posted. But someone else might.
___
sqlite-users mailing list
sqlite-users@mailingl
gt;Subject: Re: [sqlite] Unexpected REINDEX behavior.
>
>On 8/29/19 6:10 PM, Keith Medcalf wrote:
>> Do you have sqlite_stat1 or sqlite_stat4 tables present (that is,
>have you ever run analyze)?
>
>No.
>
>> If the sqlite_stat1 or sqlite_stat4 tables are present, then if
On 8/29/19 6:00 PM, Simon Slavin wrote:
> Just in case, please run an integrity-check on the database as it is before
> you delete/rebuild the index.
The python script creates the DB from scratch every time. However ...
> PRAGMA integrity_check;
... returned ...
> ok
> You might be able to le
On 8/29/19 10:56 AM, dirdi wrote:
> On 8/29/19 6:10 PM, Keith Medcalf wrote:
>> Do you have sqlite_stat1 or sqlite_stat4 tables present (that is, have you
>> ever run analyze)?
> No.
>
>> If the sqlite_stat1 or sqlite_stat4 tables are present, then if you run
>> ANALYZE; rather than reindexing
On 8/29/19 6:10 PM, Keith Medcalf wrote:
> Do you have sqlite_stat1 or sqlite_stat4 tables present (that is, have you
> ever run analyze)?
No.
> If the sqlite_stat1 or sqlite_stat4 tables are present, then if you run
> ANALYZE; rather than reindexing or dropping/recreating the index, what is
Original Message-
>From: sqlite-users [mailto:sqlite-users-
>boun...@mailinglists.sqlite.org] On Behalf Of dirdi
>Sent: Thursday, 29 August, 2019 08:10
>To: sqlite-users@mailinglists.sqlite.org
>Subject: [sqlite] Unexpected REINDEX behavior.
>
>Hi there, I noticed some -
On 29 Aug 2019, at 3:09pm, dirdi wrote:
> Does one have an explanation for this behavior?
> Is it expected that the REINDEX command produces other results than
> "manually" recreation of an index?
> If yes, under which circumstances does this happen?
> And is there some way to measure the "qual
Hi there, I noticed some - at least for me - unexpected behavior of the
REINDEX command:
I have a DB with 7 tables, 11 indexes and a size of about 140MiB. The DB
is generated by a python script parsing an XML file. Entries are added
to the tables in arbitrary order.
After the tables have been cre
15 matches
Mail list logo
