"Allen Johnson" <akjohnson78@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