On 30 July 2018 at 18:10, Eric Grange <egra...@glscene.org> wrote: > @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) >
Of course. My suggestion is to retain the same B-Tree structure, but only store rowids in there. The B-Tree would still be ordered according to the hash data - it would just be an indirect lookup to get at that data. I'm not super familiar with B-Trees or eg. how many nodes need to be touched when rebalancing, so it could well be a completely infeasible approach performance-wise :) I feel like it just depends on whether you can keep enough pages in cache to avoid constant I/O. I wonder how FTS implements prefix search... -Rowan _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
