Clojurians Log v2

Thanks for confirming my suspicions, Paula. I suspect that I will have to create a relatively complex query that fetches important relations first to get some of the properties of an ordered result…

I’m thinking that a way to get around the performance implications of ORDER BY might be to pull out a set of known relations first in a specific order and then just LIMIT the rest in another query, not caring particularly about order (do it client-side). it sucks that this will make my queries signicantly more complex. :S

LIMIT may speed things up, but sometimes it needs to do complex work to return the first item. It really depends on the query

The implementations I’m aware of (including the ones I’ve done) accomplish grouping by subquerying. i.e. The query is executed for each group. That sounds expensive, though it’s not. When you’re inside a query already, then there isn’t a lot of overhead for an implementation to do it this way. You already have a lot of data in the query already resolved, and caching is used a lot. But, it is an extra inner loop. On the other hand, ORDER BY is potentially very expensive, since an entire result needs to be eagerly returned, and then reordered. Quicksort is log(n) complexity, but it can still take time if it’s a large result.

I would expect GROUP BY to perform better. Maybe accumulating results yourself would be a little quicker, or more determinant than GROUP_CONCAT, but the grouping ought to be based on indexes, and therefore you’ll have your results grouped, even if the ordering in the groups isn’t predetermined

(`GROUP_CONCAT` demonstrates so much potential, and yet is almost useless. It frustrates me so much)