Tuesday, February 25, 2020, 3:00:09 PM, Luuk <luu...@gmail.com> wrote:
[tests snipped] > So, the index does not grow indefinitely > On 25-2-2020 14:00, Graham Holden wrote: >> It is an interesting problem. And the above is just guesswork... It would >> be good to verify experimentally that the index really does grow >> indefinitely Just to avoid (more) confusion, that speculation was from Dan's email from 2014 (I pasted his response, quoting the original email from andrewmo who raised the issue: perhaps I should have tried to add another layer of quoting...) IIRC (and I probably don't), I think it was found that there wasn't any "grow indefinitely" involved. I also suspect the cyclic nature of the post-vacuum numbers (27..52..2..27..52) is indicative of what (I think) Dan was describing, namely that the "clean-up" isn't always as "aggressive" as it potentially could be: > If you then add even more data so that > the 16th level-N b-tree is created, everything gets merged together and > we're back in the optimal state - everything in a single b-tree. However - > this b-tree is deemed to be a level-N+1 b-tree. Meaning that this time, > much more data will have to be added before everything is merged together > again. Regards, Graham Holden _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
