"Scott Carey" <scott(at)richrelevance(dot)com> 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