Hello...
On 27/1/2012 3:20 AM, Larry Knibb wrote:
On 25 January 2012 21:01, Igor Tandetnik<itandet...@mvps.org> wrote:
This index can help satisfy conditions of the form (traditional='X') or
(traditional='X' AND simplified='Y'). But it doesn't help at all for conditions
on (simplified='Y') or (traditional='X' OR simplified='Y'). So your query
devolves to a full table scan, and apparently, that just takes a long time.
Think about it this way. Imagine you have a phonebook with people's names,
sorted by last name then first name. This makes it easy to find all Smiths, or
all John Smiths, but doesn't help with the task of finding all Johns, nor all
people who are either John or Smith.
You want two separate indexes, one on hanzi(traditional) and another on
hanzi(simplified)
Thanks! Splitting the index into two did the trick and now the query
is working well.
Cheers,
Larry
I was under the impression that SQLite only uses 1 index per table per query
(not sure where I got that idea).. it's interesting to not that this works..!
Is this the recommended way to optimize OR queries involving 2 different fields
of the same table?
But as I search the SQLite website again, I find:
Note that in most cases, SQLite will only use a single index for each table in
the FROM clause of a query. The second OR-clause optimization described here is
the exception to that rule. With an OR-clause, a different index might be used
for each subterm in the OR-clause.
Something learned, thanks!
Thanks,
Mohit.
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
