On Wed, Jul 24, 2019 at 2:55 AM Justin Olbrantz <justin.olbra...@gmail.com> wrote:
> [...] my virtual table will be held completely in memory. What should I do > with the > estimatedCost value from xBestIndex? According to the documentation this > should be an approximation of the number of disk accesses for the query, > which would be 0 in this case. But it's clearly vastly faster to do a query > on an indexed column, meaning the cost for an indexed column should be much > lower than the cost for an unindexed column. How should I be doing this? > This is unfortunately similar to questions I asked on this ML in the past, with no good answers as far as I remember... For queries that mix "normal" disk-tables, in-memory-tables (i.e. the equivalent of a disk-table but with the DB file on a RAM disk, entirely in memory), and virtual-tables (e.g. accessing a C++ in-memory container of structs), the cost structure of these 3 are quite different. The last 2 are entirely in-memory both, yet the last case is quite a bit faster still (no decoding of pages/rows/varints needed). I confess to not studying the code to try to answer that myself though... --DD _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
