Re: Speeding up aggregates
От | Tom Lane |
---|---|
Тема | Re: Speeding up aggregates |
Дата | |
Msg-id | 13359.1039210966@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Speeding up aggregates (Hannu Krosing <hannu@tm.ee>) |
Ответы |
Re: Speeding up aggregates
Re: Speeding up aggregates |
Список | pgsql-performance |
Hannu Krosing <hannu@tm.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
В списке pgsql-performance по дате отправления: