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
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) |