Skip site navigation (1) Skip section navigation (2)

Re: Speeding up aggregates

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 (view raw or flat)
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

In response to

Responses

pgsql-performance by date

Next:From: Hannu KrosingDate: 2002-12-06 21:49:58
Subject: Re: Speeding up aggregates
Previous:From: Hannu KrosingDate: 2002-12-06 21:32:06
Subject: Re: Speeding up aggregates

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group