| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | Andrei Lepikhov <lepihov(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com>, Michael Paquier <michael(at)paquier(dot)xyz>, David Rowley <dgrowleyml(at)gmail(dot)com> |
| Subject: | Re: Make the transition state of avg(int2)/avg(int4)/sum(int2)/sum(int4) internal |
| Date: | 2026-09-04 15:50:22 |
| Message-ID: | 1571559.1788537022@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Andres Freund <andres(at)anarazel(dot)de> writes:
> Seems like if we do this - and I think we should - we should go broader than
> just doing this for int8[]. So yea, let's do it for float8 too.
> I think it might make sense to have an opr_sanity.sql check that verifies that
> we don't add new builtin aggregates that have an array transition state. Or
> perhaps even more strictly, test that aggregates either have an internal
> transition state, or the argument type's (for stuff like min/max).
On reflection, I'm not sure that such a policy is a win. If you go
with an internal-type transition state, then (if you want parallel
aggregation support) you need serialize/deserialize functions, and
I think also some other stuff that comes for free if the transition
state is a real SQL type. So this is not so much a clear win as
a tradeoff of which code you want to write.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alexander Lakhin | 2026-09-04 16:00:00 | Re: Stabilize recovery conflict stats checks in 031_recovery_conflict.pl |
| Previous Message | Andres Freund | 2026-09-04 15:08:39 | Re: Make the transition state of avg(int2)/avg(int4)/sum(int2)/sum(int4) internal |