| From: | Hannu Krosing <hannu(at)tm(dot)ee> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Josh Berkus <josh(at)agliodbs(dot)com>, pgsql-performance(at)postgresql(dot)org |
| Subject: | Re: Speeding up aggregates |
| Date: | 2002-12-06 21:32:06 |
| Message-ID: | 1039210325.2069.9.camel@rh72.home.ee |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
Tom Lane kirjutas L, 07.12.2002 kell 01:46:
> "Josh Berkus" <josh(at)agliodbs(dot)com> writes:
> > What have other Postgres users done to speed up aggregates on large
> > tables?
>
> FWIW, I've implemented hashed aggregation in CVS tip.
Great!
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 ?
> I have not had
> the time to try to benchmark it, but I'd be interested if anyone can
> run some tests on 7.4devel. Eliminating the need for a SORT step
> should help aggregations over large datasets.
Is there a variable to set that would disable one or another, like we
currently have for disabling various join strategies ?
> 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 ?
--
Hannu Krosing <hannu(at)tm(dot)ee>
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2002-12-06 21:42:46 | Re: Speeding up aggregates |
| Previous Message | Tom Lane | 2002-12-06 21:28:18 | Re: ORDER BY ... LIMIT.. performance |