| From: | Andres Freund <andres(at)anarazel(dot)de> |
|---|---|
| To: | David Rowley <david(dot)rowley(at)2ndquadrant(dot)com> |
| Cc: | Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>, Rajkumar Raghuwanshi <rajkumar(dot)raghuwanshi(at)enterprisedb(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Statistical aggregate functions are not working with PARTIAL aggregation |
| Date: | 2019-07-24 23:33:33 |
| Message-ID: | 20190724233333.op263jvcgcn6drxf@alap3.anarazel.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | David Rowley | 2019-07-24 23:52:33 | Re: Statistical aggregate functions are not working with PARTIAL aggregation |
| Previous Message | Andres Freund | 2019-07-24 23:24:39 | ON CONFLICT (and manual row locks) cause xmax of updated tuple to unnecessarily be set |