On Wed, Jul 24, 2019 at 3:09 PM Hick Gunter wrote:
> With the current interface, the xBestIndex function has the possibility of
> returning "effort" and "result set size" separately, instead of just an
> aggregate "effort" (which was at the time documented to assume "result set
> size").
>
Thank
g fields from a 7 field key), and also considering a
requested ORDER BY clause.
-Ursprüngliche Nachricht-
Von: sqlite-users [mailto:sqlite-users-boun...@mailinglists.sqlite.org] Im
Auftrag von Dominique Devienne
Gesendet: Mittwoch, 24. Juli 2019 11:41
An: SQLite mailing list
Betref
On Wed, Jul 24, 2019 at 10:45 AM Hick Gunter wrote:
> The speed of a virtual table depends on the backing store and software
> used to implement it.
>
[DD] Sure. virtual-tables can also access the disk and do expensive things.
[DD] I did say "example given" for my fast-pure-memory-no-decoding ca
The speed of a virtual table depends on the backing store and software used to
implement it.
We have virtual tables that reference CTree files as well as virtual tables
that reference memory sections here. The advantage is that the VT
implementation can adjust it's answers in the xBestIndex fun
4 matches
Mail list logo
