Re: Speeding up aggregates
| От | Hannu Krosing |
|---|---|
| Тема | Re: Speeding up aggregates |
| Дата | |
| Msg-id | 1039210325.2069.9.camel@rh72.home.ee обсуждение исходный текст |
| Ответ на | Re: Speeding up aggregates (Tom Lane <tgl@sss.pgh.pa.us>) |
| Ответы |
Re: Speeding up aggregates
Re: Speeding up aggregates |
| Список | pgsql-performance |
Tom Lane kirjutas L, 07.12.2002 kell 01:46: > "Josh Berkus" <josh@agliodbs.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@tm.ee>
В списке pgsql-performance по дате отправления: