Re: Hash grouping, aggregates

Bruno Wolff III <bruno@wolff.to> writes:
>   Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Greg Stark <gsstark@mit.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