On 12 Sep 2013, at 11:35pm, Roger Binns <rog...@rogerbinns.com> wrote:
> On 12/09/13 05:03, Gabor Grothendieck wrote: >> Perhaps indexing the expression in question would be an alternative >> that would keep the performance info separate from the select. > > I'd rather just do 'ANALYZE query' and have SQLite go off and do whatever > it deems necessary to gather to make the query perform well in the future. I think I prefer Roger's idea to that of messing with a vital expression. Rather than modify a command you need to work, introduce a new command which, even if it entirely fails, doesn't interfere with the operation of the SELECT. If the ANALYZE fails the SELECT (or UPDATE, or whatever) will still work, albeit more slowly. And this causes fewer problems for users who have to write code which works with many SQL engines. But because ANALYZE already means something in SQLite, perhaps it might be better to introduce a new command: STORE LIKELIHOOD test, probability or maybe REMEMBER LIKELIHOOD OF test AS probability which will store the fact that such-and-such a test has a certain probability as a new row in a table somewhere. Could be a new row in sqlite_stat3 (or sqlite_stat4), or could be in another sqlite_ table. Omitting the second parameter tells SQLite to do the evaluation itself (like ANALYZE does) and store the result. Curious users could dump the table just like people sometimes do "SELECT * FROM sqlite_stat3". Perhaps if such entries are already present when you do an ANALYZE it could update them. Simon. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
