From: Antonin Houska <ah@cybertec.at>
To: Robert Haas <robertmhaas@gmail.com>
cc: "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] WIP: Aggregation push-down
In-reply-to: 
 <CA+Tgmoa5Pp-DBJg=W8Xj8Czf-32PfxPgxwFPkA6qN2w_wPX8bg@mail.gmail.com>
References: <9666.1491295317@localhost> <8160.1493369169@localhost>
 <29613.1502983342@localhost> <14577.1509723225@localhost>
 <CAB7nPqQgB=3ZpuvSm8hVXDcPz79kn2ZGsyyoDrmQsv-B3LDMyQ@mail.gmail.com>
 <18007.1513957437@localhost>
 <CA+Tgmob8og+9HzMg1vM+3LwDm2f_bHUi9+g1bqLDTjqpw5s+nQ@mail.gmail.com>
 <20239.1516971866@localhost>
 <CA+TgmoasTkqJHo73UF_Kp2fMM33ya8cXqwrzp73zB4RgxBN+Dg@mail.gmail.com>
 <13114.1517214722@localhost>
 <CA+TgmoYDDq332NZn-51fte_F_zUbyHNSgQjdHbEdHE5sU3=f9Q@mail.gmail.com>
 <26256.1519402083@localhost>
 <CA+Tgmoa5Pp-DBJg=W8Xj8Czf-32PfxPgxwFPkA6qN2w_wPX8bg@mail.gmail.com>
Comments: In-reply-to Robert Haas <robertmhaas@gmail.com>
   message dated "Sat, 24 Feb 2018 09:08:07 -0500."
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Date: Fri, 06 Jul 2018 13:11:42 +0200
Message-ID: <11966.1530875502@localhost>
Precedence: bulk

Robert Haas <robertmhaas@gmail.com> wrote:

> 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 str=
ategy
> > number for hash index operator classes, e.g. HTBinaryEqualStrategyNumbe=
r? For
> > most types both HTEqualStrategyNumber and HTBinaryEqualStrategyNumber s=
trategy
> > would point to the same operator, but types like numeric would naturall=
y 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 no=
ted
> > upthread, grouping based on binary equality can result in excessive num=
ber of
> > groups.
> >
> > One open question is whether the binary equality operator needs a separ=
ate
> > operator class or not. If an opclass cares only about the binary equali=
ty, its
> > hash function(s) can be a lot simpler.
>=20
> 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.

I suppose you mean pg_operator, not pg_type. What I don't like about this is
that the new field would only be useful for very little fraction of
operators.

On the other hand, the drawback of an additional operator classes is that w=
e'd
have to modify almost all the existing operator classes for the hash AM. (T=
he
absence of the new strategy number in an operator class cannot mean that the
existing equality operator can be used to compare binary values too, because
thus we can't guarantee correct behavior of the already existing user-defin=
ed
operator classes.)


--=20
Antonin Houska
Cybertec Sch=C3=B6nig & Sch=C3=B6nig GmbH
Gr=C3=B6hrm=C3=BChlgasse 26, A-2700 Wiener Neustadt
Web: https://www.cybertec-postgresql.com