Re: Partial aggregates pushdown - Mailing list pgsql-hackers

On Tue, 25 Jun 2024 at 08:33, Fujii.Yuki@df.MitsubishiElectric.co.jp
<Fujii.Yuki@df.mitsubishielectric.co.jp> wrote:
> Actually, I have other tasks about "PARTIAL_AGGREAGATE" keyword
> to respond Requirement1 and Requirement2 in the following mail.
>
https://www.postgresql.org/message-id/TYAPR01MB3088755F2281D41F5EEF06D495F92%40TYAPR01MB3088.jpnprd01.prod.outlook.com

No problem. I totally think it makes sense to focus on basic
PARTIAL_AGGREGATE first. Which is also why I suggested splitting the
patchset up in multiple patches. That way it's easier to get everyone
aligned on PARTIAL_AGGREGATE behaviour for non-internal transtypes,
which would already be a huge improvement over the current situation
in my opinion.

> After that tasks, I plan to compare your proposal with mine seriously, with additional POC patches if necessary.

Sounds great! To be clear, I'm not sure which proposal is best. I
mainly thought mine seemed interesting because it doesn't require
additional columns. But maybe the benefits that the extra columns in
your proposal brings are worth adding those extra columns.

> I see. It seems that adding new natives might make it easier to transmit the state values between local and remote
havedifferent major versions.
 
> However, in my opinion, we should be careful to support the case in which local and remote have different major
versions,
> because the transtype of an aggregate function would may change in future major version due to
> something related to the implementation.
> Actually, something like that occurs recently, see
> https://github.com/postgres/postgres/commit/519fc1bd9e9d7b408903e44f55f83f6db30742b7
> I think the transtype of an aggregate function quite more changeable than retype.
> Consequently, so far, I want to support the cases in which local and remote have the same major version.
> If we try to resolve the limitation, it seems to need more additional codes.

Hmm, that's a very good point. Indeed cross-major-version partial
aggregates pushdown would not be fully solved with this yet.

> And, I'm afraid that adding typinput/typoutput bothers the developers.
> They also have to create a new native types in addition to create their new aggregate functions.
> I wonder if this concern might outweigh the benefits for debugging.
> And, if skipping send/receive, they have to select only the text representation on
> the transmission of the state value. I think it is narrow.

I kinda agree with this argument. But really this same argument
applies just as well for regular CREATE TYPE. Developers are forced to
implement typinput/typoutput, even though send/receive might really be
enough for their usecase. So in a sense with your proposal, you give
transtypes a special status over regular types: i.e. transtypes are
the only types where only send/receive is necessary.

So that leaves me two questions:
1. Maybe CREATE TYPE should allow types without input/output functions
as long as send/receive are defined. For these types text
representation could fall back to the hex representation of bytea.
2. If for some reason 1 is undesired, then why are transtypes so
special. Why is it fine for them to only have send/receive functions
and not for other types?