Re: Combining Aggregates

On 21 January 2016 at 01:44, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:

> On Wed, Jan 20, 2016 at 7:38 AM, David Rowley
> <david(dot)rowley(at)2ndquadrant(dot)com> wrote:
> >> To my mind, priority #1 ought to be putting this fine new
> >> functionality to some use. Expanding it to every aggregate we've got
> >> seems like a distinctly second priority. That's not to say that it's
> >> absolutely gotta go down that way, but those would be my priorities.
> >
> > Agreed. So I've attached a version of the patch which does not have any
> of
> > the serialise/deserialise stuff in it.
> >
> > I've also attached a test patch which modifies the grouping planner to
> add a
> > Partial Aggregate node, and a final aggregate node when it's possible.
> > Running the regression tests with this patch only shows up variances in
> the
> > EXPLAIN outputs, which is of course expected.
>
> That seems great as a test, but what's the first patch that can put
> this to real and permanent use?

There's no reason why parallel aggregates can't use
the combine_aggregate_state_d6d480b_2016-01-21.patch patch.

In this patch I've changed aggregates_allow_partial() so that it properly
determines what is possible based on the aggregates which are in the query.
This now, of course restricts the aggregates to "internal only" when the
agg state type is INTERNAL, providing there's a combine function, of course.

Parallel aggregate should work with all the MAX() and MIN() functions and a
handful of other ones, I've managed to borrow various existing function as
the combine function for many aggregates:

# select count(*) from pg_aggregate where aggcombinefn <> 0;
count
-------
58
(1 row)

--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services