While looking through the SQLite3 source trying to find answers to some questions I had about virtual tables, I noticed that the memory DB is implemented as a VFS rather than a database. Is my understanding correct that this means that the estimated cost the query planner uses for memory tables will be equal to that of the same database on disk? Shouldn't memory DBs always have a much lower cost to cause the query planner to prefer intensive operations on memory DBs rather than disk DBs? I know there's a field in the table definition for cost multiplier that could perhaps be used for this purpose, but as far as I can tell this is only ever used by ANALYZE and it's theoretically impossible that memory DBs could even use it.
As for the question I was originally looking for an answer to, I am writing a virtual table for a different file format, and it is expected that 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? -- Justin Olbrantz (Quantam) "Ardente veritate Urite mala mundi Ardente veritate Incendite tenebras mundi" _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
