On Fri, Feb 23, 2018 at 11:08 AM, Antonin Houska <a...@cybertec.at> wrote: > I spent some more time thinking about this. What about adding a new strategy > number for hash index operator classes, e.g. HTBinaryEqualStrategyNumber? For > most types both HTEqualStrategyNumber and HTBinaryEqualStrategyNumber strategy > would point to the same operator, but types like numeric would naturally have > them different. > > Thus the pushed-down partial aggregation can only use the > HTBinaryEqualStrategyNumber's operator to compare grouping expressions. In the > initial version (until we have useful statistics for the binary values) we can > avoid the aggregation push-down if the grouping expression output type has the > two strategies implemented using different functions because, as you noted > upthread, grouping based on binary equality can result in excessive number of > groups. > > One open question is whether the binary equality operator needs a separate > operator class or not. If an opclass cares only about the binary equality, its > hash function(s) can be a lot simpler.
Hmm. How about instead adding another regproc field to pg_type which stores the OID of a function that tests binary equality for that datatype? If that happens to be equal to the OID you got from the opclass, then you're all set. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
