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

Reply via email to