On Fri, Oct 16, 2009 at 2:48 PM, Pavel Ivanov <paiva...@gmail.com> wrote: > Yes, pretty interesting results. I didn't expect that. :) > Query plan seems to suggest that SQLite executes query not in the way > you said but first takes tit table, joins epgdata to it and then joins > tit1 and tit2 to it. So it should be executed faster than you > thought... > > I've played with your queries a bit and found the only way to force > SQLite to execute query the way I've intended - to change table > epgdata so that id is not "integer primary key" but has a non-unique > (!) index on it. :) But of course that will not mean that query > execution would be the fastest in this case. > I'm surprised and impressed with SQLite's optimizer. :) > > BTW, to make your query fastest you need index on (lang, epgdata_id, > tittext) instead of (lang, tittext, epgdata_id). Even for this > particular query tittext shouldn't be in the index at all. > > > Pavel
I think LIKE queries can use an index if they are prefix searches bar LIKE "FOO%" can use an index but bar LIKE "%FOO%" is that right? B _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
