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