On Wed, Jan 20, 2016 at 7:38 AM, David Rowley <david.rowley@2ndquadrant.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;
