> ...
> > 1)  is there an orthodox method of indicating that a query 
> plan request from
> > xBestIndex is a no-go,
> Give that plan a huge estimatedCost.
> As a backup, in the exceedingly unlikely event that SQLite chooses
> your no-go plan in spite of the huge estimatedCost, also provide a
> unique idxNum and if xFilter sees that idxNum, have xFilter throw an
> error with error message text that is something like "query planner
> could not find an acceptable solution".
> ...
> And I guess as a bonus 4th question:  What is the established orthodoxy in
> picking estimatedCost anyway?
> ...
> It is not overly sensitive to the scale of your cost estimates.   For
> ...
> You don't know how to estimate that?  Then guess.  As long as the
> relative costs for other invocations of xBestIndex on the same virtual
> table are in reasonable proportion, everything should work fine.

Thanks!  I like the idxNum tweak for the error message; I'll add that stuff

And the info about relative costs _on_the_same_virtual_table_ is very
enlightening because I suppose the converse is true, that the extimated cost
relative to OTHER virtual/physical tables does NOT matter.


sqlite-users mailing list

Reply via email to