On Sat, Mar 17, 2018 at 1:28 AM, Richard Hipp <d...@sqlite.org> wrote:
> On 3/16/18, R Smith <ryansmit...@gmail.com> wrote: > > It's interesting to fathom what hypothesis is being tested with this > pole... > > INSERT operations on a table with AUTOINCREMENT do a full-table scan > against the sqlite_sequence table. I'm wondering if it is worthing > adding extra logic to do some kind of indexed lookup. For a schema > with just a few AUTOINCREMENT tables, there is really no point in > trying to use an index. But if you have hundreds of AUTOINCREMENT > tables, some kind of index might be worthwhile. > Hi Richard. Is 8.d from https://www.sqlite.org/draft/releaselog/current.html the result of this inquiry? And is there a chance the "some kind of indexed lookup" you mention above is likely to land in the future? I'm obviously asking because we (my employer) is the heaviest (publicly reported) user of AUTOINCREMENT, and I wonder if we're not incurring unbeknownst until now insert penalties from those full scans. What's the threshold you estimate (or measured) in AUTOINCREMENT table count for the full-scan O(N) to be slower than an hypothetical indexed-lookup O(log N) of sqlite_sequence? If we insert 1M rows in that schema.i DB with 117 AUTOINCREMENT tables, are we really full-scanning up to 117M rows just to get the ROWIDs of those 1M rows? Thanks for your insights into this. --DD _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
