Hi,
Since
commit a7de3dc5c346e07e0439275982569996e645b3c2
Author: Robert Haas <rh...@postgresql.org>
Date: 2016-01-20 13:46:50 -0500
Support multi-stage aggregation.
Aggregate nodes now have two new modes: a "partial" mode where they
output the unfinalized transition state, and a "finalize" mode where
they accept unfinalized transition states rather than individual
values as input.
These new modes are not used anywhere yet, but they will be necessary
for parallel aggregation. The infrastructure also figures to be
useful for cases where we want to aggregate local data and remote
data via the FDW interface, and want to bring back partial aggregates
from the remote side that can then be combined with locally generated
partial aggregates to produce the final value. It may also be useful
even when neither FDWs nor parallelism are in play, as explained in
the comments in nodeAgg.c.
David Rowley and Simon Riggs, reviewed by KaiGai Kohei, Heikki
Linnakangas, Haribabu Kommi, and me.
there's both advance_transition_function and advance_combine_function,
fulfilling closely related duties.
While working on that code (making transition and combine functions go
through expression evaluation, so they can be JITed), I noticed a small
difference in behaviour beteween the two:
The plain transition case contains:
if (pergroupstate->transValueIsNull)
{
/*
* Don't call a strict function with NULL inputs. Note
it is
* possible to get here despite the above tests, if the
transfn is
* strict *and* returned a NULL on a prior cycle. If
that happens
* we will propagate the NULL all the way to the end.
*/
return;
}
how come similar logic is not present for combine functions? I don't see
any checks preventing a combinefunc from returning NULL, nor do I see
https://www.postgresql.org/docs/devel/static/sql-createaggregate.html
spell out a requirement that that not be the case.
Greetings,
Andres Freund
