Re: Slow query with a lot of data

Am 20.08.2008 um 20:28 schrieb Tom Lane:

> "Scott Carey" <scott@richrelevance.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

The datatypes are both integers. There is no DISTINCT in this query.
Thanks anyway!