Re: [HACKERS] WIP: Aggregation push-down
От | Robert Haas |
---|---|
Тема | Re: [HACKERS] WIP: Aggregation push-down |
Дата | |
Msg-id | CA+Tgmoa5Pp-DBJg=W8Xj8Czf-32PfxPgxwFPkA6qN2w_wPX8bg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] WIP: Aggregation push-down (Antonin Houska <ah@cybertec.at>) |
Ответы |
Re: [HACKERS] WIP: Aggregation push-down
|
Список | pgsql-hackers |
On Fri, Feb 23, 2018 at 11:08 AM, Antonin Houska <ah@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
В списке pgsql-hackers по дате отправления: