@Rowan Worth > Doesn't that problem already exist with the current index? Except worse > because it's storing the cryptographic hash *and* the rowid.
No, because SQLite is using a B-Tree (and with cryptographic hashes, it should even take less effort to balance) On Mon, Jul 30, 2018 at 12:05 PM, Rowan Worth <row...@dug.com> wrote: > On 30 July 2018 at 17:53, Eric Grange <egra...@glscene.org> wrote: > > > @Rowan Worth > > > What if you could create a "lite" index, which stores just the rowids > in > > a particular order and > > > refers back to the table for the rest of the column data? > > > > As I have millions of rows, and data could get inserted anywhere in that > > index (given the values are > > essentially random), maintaining such an index would not be light work. > > > > Doesn't that problem already exist with the current index? Except worse > because it's storing the cryptographic hash *and* the rowid. > > I wasn't suggesting that you manage such an index yourself fwiw, but as a > potential future feature for sqlite - a simple mechanism to control space > used by an index. > > -Rowan > _______________________________________________ > sqlite-users mailing list > sqlite-users@mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users > _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
