Re: [sqlite] [EXTERNAL] Virtual Tables xConnect Called When?

2019-07-25 Thread Justin Olbrantz
The reason I asked the question is because for my virtual table which has a
"backing store" (more precisely it needs to have CREATE VIRTUAL TABLE
called to associate a loaded file with the table to be created via a table
parameter), I have separate implementations for xCreate and xConnect.
xCreate is working fine (in fact it's already handling queries properly),
but I'm not seeing any calls to xConnect including in queries (as you
suggest). So for a table with different xCreate and xConnect functions,
when would xConnect be called?

-- 
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


[sqlite] Virtual Tables xConnect Called When?

2019-07-24 Thread Justin Olbrantz
The documentation says that "The difference is that xConnect is called to
establish a new connection to an existing virtual table whereas xCreate is
called to create a new virtual table from scratch." But this leaves me
unclear on the circumstances where xConnect would be called (assuming I
have a non-eponymous table). How would you create a new connection to an
exiting virtual table?

-- 
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


[sqlite] Estimated Costs and Memory DBs

2019-07-23 Thread Justin Olbrantz
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