On 7 Apr 2013, at 3:51pm, Stephen Chrzanowski <pontia...@gmail.com> 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? Take for example if I have a list of > dollars and cents being returned from a query. I want the 5 top highest > cost items out of 6 possibilities, if I keep the top 5 unsorted, item 6 > could have been the very top of the list. Thereby making the desired > result wrong. The optimization I was thinking of was simpler than that. An example would have been ORDER BY score DESC LIMIT 1. Theoretically the engine could notice that all it needed was the top-scoring result, and just do a quick scan for the highest score, which would be less effort than sorting all the rows into order. I can imagine one of the big heavy-duty SQL engines doing this but perhaps not SQLite because it would require a lot of extra code and introduce a lot of test cases. A server/client SQL system can do a kind of progressive indexing because it runs on a server and can do a lot of processing without tying up the client computer. So with the above type of SELECT the engine will return the first result as the client asks for it. Then it will immediately try to find the second result, then the third, etc. aiming to have each result ready before the client asks for it. I believe MySQL does this under certain conditions. Simon. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
