Stephen Chrzanowski wrote: > I don't know if it'd be an interesting optimization. Who's to say what the > order ends up as prior to the sort?
When doing a merge sort, it would actually be possible to abort the very last merge step when the first LIMIT entries have been merged. I might be wrong, but it looks as if the implementation of OP_SorterNext (sqlite3VdbeSorterNext) does this, by doing the last merge step only for the next record that is currently being needed. > Indexes also aren't used for sorting, only for finding relevant data. sqlite> create table t(x,y); sqlite> explain query plan select * from t order by x; 0|0|0|SCAN TABLE t (~1000000 rows) 0|0|0|USE TEMP B-TREE FOR ORDER BY sqlite> create index tx on t(x); sqlite> explain query plan select * from t order by x; 0|0|0|SCAN TABLE t USING INDEX tx (~1000000 rows) (BTW, that "TEMP B-TREE" is an in-memory index, and gets written out to disk for a merge sort only when it becomes too big.) Regards, Clemens _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
