Hello,
My query wont use the R-Tree index if I provide an ORDER BY clause and
performance degrades considerably. Obviously I can work around with by
making the R-Tree query a subquery and sorting the results, but would
like to know why this is necessary? I've done an VACUUM and ANALYZE.
Is this expected behavior? I haven't found any mention of it in the docs.
The schema is akin to the following:
CREATE TABLE events (
id INTEGER PRIMARY KEY,
cal_id INTEGER NOT NULL, -- This is a FK, ~75 possible values
begins TIMESTAMP NOT NULL, -- unix epoch
endsTIMESTAMP NOT NULL -- unix epoch
);
INSERT INTO events VALUES (null, 123, 1356624000, 1356634800);
INSERT INTO events VALUES (null, 12452, 1356624000, 1356634800);
INSERT INTO events VALUES (null, 34653, 1356624000, 1356634800);
INSERT INTO events VALUES (null, 89287, 1356624000, 1356634800);
-- 55000 rows in events for testing, production will have 500k-1m rows
CREATE VIRTUAL TABLE events_idx USING rtree(id, begins, ends);
INSERT INTO events_idx (id,begins,ends) SELECT id,begins,ends FROM events;
-- Query A, runtime is 300ms+, 8ms without the ORDER BY
SELECT DISTINCT *
FROMevents_idx AS ei
INNER JOIN events AS e ON e.id = ei.id
WHERE ei.begins < 1356753600
AND ei.ends > 1356624000
AND e.cal_id IN (123,12452,567,1234,34653,4249,89287)
ORDER BYe.begins, e.ends - e.begins;
-- Query B, runtime is ~8ms
SELECT * FROM
(
SELECT DISTINCT *
FROMevents_idx AS ei
INNER JOIN events AS e ON e.id = ei.id
WHERE ei.begins < 1356753600
AND ei.ends > 1356624000
AND e.cal_id IN (123,12452,567,1234,34653,4249,89287)
) AS sub
ORDER BYsub.begins, sub.ends - sub.begins;
Thank you for your time.
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users