From: Antonin Houska <ah@cybertec.at>
To: Robert Haas <robertmhaas@gmail.com>
cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] WIP: Aggregation push-down
In-reply-to: 
 <CA+TgmoYDDq332NZn-51fte_F_zUbyHNSgQjdHbEdHE5sU3=f9Q@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>
Comments: In-reply-to Robert Haas <robertmhaas@gmail.com>
   message dated "Mon, 29 Jan 2018 09:43:49 -0500."
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Date: Fri, 23 Feb 2018 17:08:03 +0100
Message-ID: <26256.1519402083@localhost>
Precedence: bulk

Robert Haas <robertmhaas@gmail.com> wrote:

> On Mon, Jan 29, 2018 at 3:32 AM, Antonin Houska <ah@cybertec.at> wrote:
> > I think of a variant of this: implement an universal function that test=
s the
> > binary values for equality (besides the actual arguments, caller would =
have to
> > pass info like typlen, typalign, typbyval for each argument, and cache =
these
> > for repeated calls) and set pg_proc(oprcode) to 0 wherever this functio=
n is
> > sufficient. Thus the problematic cases like numeric, citext, etc. would=
 be
> > detected by their non-zero oprcode.
>=20
> I don't think that's a good option, because we don't want int4eq to
> have to go through a code path that has branches to support varlenas
> and cstrings.  Andres is busy trying to speed up expression evaluation
> by removing unnecessary code branches; adding new ones would be
> undoing that valuable work.

I spent some more time thinking about this. What about adding a new strategy
number for hash index operator classes, e.g. HTBinaryEqualStrategyNumber? F=
or
most types both HTEqualStrategyNumber and HTBinaryEqualStrategyNumber strat=
egy
would point to the same operator, but types like numeric would naturally ha=
ve
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.

--=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