Am 20.08.2008 um 20:28 schrieb Tom Lane:
"Scott Carey" <scott@xxxxxxxxxxxxxxxxx> writes:
The planner actually thinks there will only be 28704 rows returned
of width
12. But it chooses to sort 53 million rows before aggregating.
Thats
either a bug or there's something else wrong here. That is the
wrong way
to aggregate those results no matter how much work_mem you have
unless I'm
completely missing something...
That does look weird. What are the datatypes of the columns being
grouped by? Maybe they're not hashable?
Another forcing function that prevents use of HashAgg is DISTINCT
aggregates, but you don't seem to have any in this query...
regards, tom lane
The datatypes are both integers. There is no DISTINCT in this query.
Thanks anyway!
