Re: parallel aggregation

On Wed, 12 Apr 2023 at 22:14, Alexander Saydakov <saydakov(at)yahooinc(dot)com> wrote:
>
> I have a few questions regarding aggregate functions that would be parallel safe.
> 1. do the inputs of combinefunc always go through serialfunc-deserialfunc or they can come directly from sfunc (worker on the same machine, perhaps)?

Only aggregates with an INTERNAL transition state must be serialised
and deserialised. Non-internal state aggregates i.e ones that have a
corresponding database type, can be pushed through the normal means
that we transfer tuples from parallel workers to the main process
without any serialisation or deserialisation at the other end.

All serial functions must return bytea and accept a single INTERNAL
parameter, so you can't even make a serial func for an aggregate
that's not got an INTERNAL aggregate state type.

> 2. can the result of combinefunc ever be fed to sfunc as opposed to other combiners or finalfunc?

combinefuncs take 2 STYPEs, so it's not valid to pass those to an
SFUNC (those are only given a BASETYPE to transition into the
aggregate state). The finalfunc will be called (if it exists) during
the Finalize Aggregate plan node. The Finalize Aggregate node also
gathers intermediate aggregate states from parallel workers and calls
the combinefunc on ones from the same group, so yes, the finalfunc
will be called on aggregate states that have been combined with the
combinefunc.

> I have in mind a scenario, when a different data structure is used in the combine stage. For that it would be good if the conversion can happen in serialfunc-deserialfunc, and the combiner does not even know about the other structure used for state transition during aggregation. If that is the case, the only problem remains with the finalfunc. It has to be ready to receive both types.

What's the use case for that?

David