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