| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Hannu Krosing <hannu(at)tm(dot)ee> |
| Cc: | Josh Berkus <josh(at)agliodbs(dot)com>, pgsql-performance(at)postgresql(dot)org |
| Subject: | Re: Speeding up aggregates |
| Date: | 2002-12-06 21:42:46 |
| Message-ID: | 13359.1039210966@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
Hannu Krosing <hannu(at)tm(dot)ee> writes:
> This should also make it easier to implement all kinds of GROUP BY
> ROLLUP|CUBE|GROUPING SETS|() queries.
> Do you have any near-term plans for doing them ?
Not me.
> Is there a variable to set that would disable one or another, like we
> currently have for disabling various join strategies ?
enable_hashagg. I didn't think about one to prevent the old style.
>> Note that even though there's no SORT, the sort_mem setting is used
>> to determine the allowable hashtable size, so a too-small sort_mem
>> might discourage the planner from selecting hashed aggregation.
> Do you mean that hashed aggregation can't overflow to disk, or would it
> just be too slow ?
I didn't write any code to let it overflow to disk --- didn't seem
likely to be useful. (You're probably better off with a sort-based
aggregation if there are too many distinct grouping keys.)
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Hannu Krosing | 2002-12-06 21:49:58 | Re: Speeding up aggregates |
| Previous Message | Hannu Krosing | 2002-12-06 21:32:06 | Re: Speeding up aggregates |