On Nov 16, 2009, at 7:02 PM, Tim Romano wrote: > Thanks for the reply. Sorry, I didn't make my question clear > enough. I > was trying to find out if the following statement would be true: > > If the value after the LIKE operator is a string literal (as distinct > from a bound parameter) then > the choice of function to compile the statement will have no effect on > the optimizer; > i.e. the optimizer is compiler-function-agnostic when the value after > the LIKE operator is a string literal.
Correct. > > <docs>The LIKE optimization is not attempted if the right-hand side > is a > parameter and the statement was prepared using sqlite3_prepare() or > sqlite3_prepare16() . </docs> > The reason for this is that if the RHS of the LIKE is a parameter, the statement will need to be re-prepared whenever the parameter is re- bound because SQLite has to know the actual text value of the RHS in order to figure out if indices can be used or not. But re-prepare is not possible with sqlite3_prepare() and sqlite3_prepare16() since those routine do not store the original SQL text. sqlite3_prepare_v2() and sqlite3_prepare16_v2(), on the other hand, do store the original SQL text and can re-prepare and so they can optimize for parameters on the RHS of a LIKE. D. Richard Hipp d...@hwaci.com _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
