"Allen Johnson" <akjohnso...@gmail.com> writes: > I did run into an issue where we are performing a group-by on about 10 > columns followed by an order-by of about 5 columns. This query was taking > twice as long as Oracle. When looking at the explain plan, Postgres seems to > be using all the columns in the group-by for sorting instead of _only_ using > what is in the order-by.
If it's using a sort-uniq type of plan (which it is), it has to sort by all the grouping columns, else the results won't be correct. In practice, I really doubt this would make a measurable performance difference, since most row comparisons would arrive at a result before they got to the lowest-order columns. I think your gripe may actually have to do with a misestimate of the relative costs of hash- and sort-based grouping, but analyze results on a toy example don't illuminate that sort of problem at all :-( regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs