| From: | Moritz Onken <onken(at)houseofdesign(dot)de> |
|---|---|
| To: | |
| Cc: | pgsql-performance(at)postgresql(dot)org |
| Subject: | Re: Slow query with a lot of data |
| Date: | 2008-08-21 07:04:38 |
| Message-ID: | 07C8F893-C524-44CD-831D-EA1240C429AA@houseofdesign.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
Am 20.08.2008 um 20:28 schrieb Tom Lane:
> "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
The datatypes are both integers. There is no DISTINCT in this query.
Thanks anyway!
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Moritz Onken | 2008-08-21 07:45:32 | Re: Slow query with a lot of data |
| Previous Message | Moritz Onken | 2008-08-21 07:03:53 | Re: Slow query with a lot of data |