Re: Hash grouping, aggregates

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Bruno Wolff III <bruno(at)wolff(dot)to>
Cc: Greg Stark <gsstark(at)mit(dot)edu>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Hash grouping, aggregates
Date: 2003-02-11 16:39:52
Message-ID: 26171.1044981592@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Bruno Wolff III <bruno(at)wolff(dot)to> writes:
> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Greg Stark <gsstark(at)mit(dot)edu> writes:
>>> The neat thing is that hash aggregates would allow grouping on data types that
>>> have = operators but no useful < operator.
>>
>> Hm. Right now I think that would barf on you, because the parser wants
>> to find the '<' operator to label the grouping column with, even if the
>> planner later decides not to use it. It'd take some redesign of the
>> query data structure (specifically SortClause/GroupClause) to avoid that.

> I think another issue is that for some = operators you still might not
> be able to use a hash. I would expect the discussion for hash joins in
> http://developer.postgresql.org/docs/postgres/xoper-optimization.html
> would to hash aggregates as well.

Right, the = operator must be hashable or you're out of luck. But we
could imagine tweaking the parser to allow GROUP BY if it finds a
hashable = operator and no sort operator. The only objection I can see
to this is that it means the planner *must* use hash aggregation, which
might be a bad move if there are too many distinct groups.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Greg Copeland 2003-02-11 16:42:54 Re: Changing the default configuration (was Re:
Previous Message Tom Lane 2003-02-11 16:20:14 Changing the default configuration (was Re: [HACKERS] PostgreSQL Benchmarks)