Yes, that's right. Pavel
On Fri, Oct 16, 2009 at 9:05 AM, Brad Phelan <bradphe...@xtargets.com> wrote: > 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 > _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
