Re: Statistical aggregate functions are not working with PARTIALaggregation - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Statistical aggregate functions are not working with PARTIALaggregation
Date
Msg-id 20190724233333.op263jvcgcn6drxf@alap3.anarazel.de
Whole thread Raw
In response to Re: Statistical aggregate functions are not working with PARTIAL aggregation  (David Rowley <david.rowley@2ndquadrant.com>)
Responses Re: Statistical aggregate functions are not working with PARTIAL aggregation  (David Rowley <david.rowley@2ndquadrant.com>)
List pgsql-hackers
Hi,

On 2019-07-25 10:36:26 +1200, David Rowley wrote:
> I'd like to do > much more in nodeAgg.c, TBH. It would be good to remove some code from
> nodeAgg.c and put it in the planner.

Indeed!


> I'd like to see:
> 
> 1) Planner doing the Aggref merging for aggregates with the same
> transfn etc.

Makes sense.

I assume this would entail associating T_Aggref expressions with the
corresponding Agg at an earlier state? The whole business of having to
prepare expression evaluation, just so ExecInitAgg() can figure out
which aggregates it has to compute always has struck me as
architecturally bad.


> 2) Planner trying to give nodeAgg.c a sorted path to work with on
> DISTINCT / ORDER BY aggs

That'll have to be a best effort thing though, i.e. there'll always be
cases where we'll have to retain the current logic (or just regress
performance really badly)?

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: ON CONFLICT (and manual row locks) cause xmax of updated tuple tounnecessarily be set
Next
From: David Rowley
Date:
Subject: Re: Statistical aggregate functions are not working with PARTIAL aggregation