On Mon, Sep 21, 2009 at 8:27 AM, Pavel Ivanov <paiva...@gmail.com> wrote: > > There's no way to optimize your query to be fast in both situations. > LIMIT clause is pretty hard to optimize. Maybe just to have a closer > look at the application structure - maybe it's not so necessary to do > ORDER BY or maybe LIMIT can be moved to inner query... > But for this particular case I think it's pretty reasonable to use > INDEXED BY clause despite what documentation says (it discourages > usage for common cases). >
Yeah, that's what I was afraid of. :) I guess I'll end up just tracking the number of val_table entries which match each path, then totaling up the # of matching entries first to get a count of how many rows my real query is going to match. Using that, and the LIMIT BY items, I can maybe heuristically guess which indexing method will be faster for when I do the real query. Seems like a pain for this relatively simple scenario, but I can see how it'd be deceptively easy-looking to optimize. Thanks for the response -- Matthew L. Creech _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
