Bruno Wolff III <[EMAIL PROTECTED]> writes: > Tom Lane <[EMAIL PROTECTED]> wrote: >> Greg Stark <[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
