On Sun, Apr 6, 2014 at 10:23 PM, Dominique Devienne <ddevie...@gmail.com> wrote:
>
> If the answer to either question above is true, then a specialized
> vtable would be both more convenient and faster, no?
>
Hmm... If logical peculiarity of vtable approach (when
where-constrained queries might be larger than full-scan one) is
acceptable by sqlite (mentioned in my other post), then where
expression might serve as parameters so a possible hybrid might be
possible (also inspired by the recent discussion of creating user
functions on the fly). For example, a virtual table that accepts a
Select statement might look like
CREATE VIRTUAL TABLE vcommalist USING QueryVirtualizer('WITH RECURSIVE
.... :commalist .... ')
And the actual query using it might look like
SELECT * FROM vcommalist WHERE commalist='1,2,3,4,5'
This one served more like shortcut, but probably a more broad version
is possible when the parameter to virtual table is a print formatted
string so one can dynamically customize parameters general parameters
can't, i.e., table names, output column names etc.
Multiply parameters would be great, but with current state of things
the implementation still should use some kind of workaround to ensure
correct results so should always return huge estimatedCost in
xBestIndex if the constrained arrived doesn't contain at least one
required parameter (WHERE clause lacks one) and low one if all
parameters are provided. I think that sqlite might as well interpret
estimatedCost equal to -1 as a ban to use this index.
Max
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
