Hi All,
Sorry for the long email, but the background is probably needed :)
1. We have a geographical query that is supported by an R-Tree index. A
join is required to filter by category while restricting by the bounding
box. On the main table (objects), we have an index IDX_OBJ_CAT on
Objects(cat) and we have a virtual index on the RTree table (Objects_Index).
We felt that the query was a bit slow:
select * FROM Objects, Objects_Index
WHERE Objects.id = Objects_Index.id
AND minx <= 668632 + 250 AND maxx >= 668632 - 250
AND miny <= 1518661 + 250 AND maxy >= 1518661 - 250
AND CAT=25;
Doing an explain query plan revealed that SQlite was scanning Objects
with the IDX_OBJ_CAT first and then using the R-Tree. Without
restricting by CAT, we found the query was much faster and was using
only the virtual R-Tree index.
We wanted to get SQLite to use the R-Tree first, so we tried a few
different things - eventually, we killed the IDX_OBJ_CAT index and the
query became (yes, wait for it) almost 100x faster!
So, now we want to go about fixing our schema and queries to benefit
from this.
What do you recommend? What would be the best way to make SQLite3 use
the R-Tree? We're a bit unsure about dropping the category index since
we are not sure which other queries will be affected.
2. While searching around, I found INDEXED BY and NOT INDEXED and NOT
INDEXED worked very well for this query. But, an email from 2009 said:
"many are of the opinion that this feature is prone to misuse."
> There is the "INDEXED BY" clause. But many are of the opinion that
> this feature is prone to misuse.
>
> http://www.sqlite.org/lang_indexedby.html
>
> Dan.
What's the current wisdom?
Thanks,
Mohit.
_______________________________________________
sqlite-users mailing list
[email protected]
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
