From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Allen Johnson" <akjohnson78(at)gmail(dot)com> |
Cc: | pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: BUG #5294: Sorts on more than just the order-by clause |
Date: | 2010-01-21 21:00:06 |
Message-ID: | 13647.1264107606@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
"Allen Johnson" <akjohnson78(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Allen Johnson | 2010-01-21 21:27:57 | Re: BUG #5294: Sorts on more than just the order-by clause |
Previous Message | Tom Lane | 2010-01-21 17:45:14 | Re: add primary key doesn't block? |