> ... > > 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 in. 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. -dave _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
