I am not quite sure what it is, and why it is, that you are doubting, Jean-Christophe.
Queries using GLOB do use the index on the column in question (i.e. optimization is attempted) Queries using LIKE do not use that index if the LIKE operator has been overridden. You could confirm this claim from the docs and/or by using EXPLAIN QUERY PLAN, assuming you had access to a version of SQLite where the LIKE operator has been overridden (as it has been in Adobe AIR, Firebird, and in the version that ships with the System.Data.SQLite .NET provider as well, IIRC. Regards Tim Romano On Mon, Apr 26, 2010 at 9:24 AM, Jean-Christophe Deschamps <j...@q-e-d.org>wrote: > At 14:31 26/04/2010, you wrote: > > >If the implementation of SQLite you are using overrides the LIKE operator > >(as more than a few do), then SQLite will not make use of an index on the > >column in question. Use the GLOB operator instead. > > I doubt it. GLOB is absolutely nothing more or less than an invokation > of the same code for LIKE but with slightly different > parameters. Except if people have made a completely differing version, > departing from the architecture of the standard SQLite code (and there > is little reason to, if any) AND have made LIKE and GLOB two completely > distinct functions, there shouldn't be any significant difference in > running time (for equivalent queries, of course). > > Also if ever LIKE is overloaded, then GLOB gets excluded from standard > optimization, except large changes in SQLite code. > > _______________________________________________ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
