RE: Partial aggregates pushdown - Mailing list pgsql-hackers

From Fujii.Yuki@df.MitsubishiElectric.co.jp"
Subject RE: Partial aggregates pushdown
Date
Msg-id TYAPR01MB308841016A3F1AE8247BAA6495C02@TYAPR01MB3088.jpnprd01.prod.outlook.com
Whole thread Raw
In response to Re: Partial aggregates pushdown  (Jelte Fennema-Nio <postgres@jeltef.nl>)
Responses Re: Partial aggregates pushdown
List pgsql-hackers
Hi Jelte,

Thank you for your comment!
> From: Jelte Fennema-Nio <postgres@jeltef.nl>
> Sent: Tuesday, June 11, 2024 11:00 PM
> How about instead of trying to serialize the output of serialfn/deserialfn, instead we don't use the "internal" type
and
> create actual types in pg_type for these transtypes? Then we can simply use the in/out and recv/send functions of
those
> types to serialize the values of the partial aggregate over the network.
> Instead of having to rely on serialfn/deserialfn to be network-safe (which they probably aren't).
> 
> That indeed still leaves the pseudo types. Since non of those pseudotypes have a working in/recv function (they
always
> error by definition), I agree that we can simply not support those.
> 
> Basically that would mean that any aggregate with a non-internal and non-pseudotype as a transtype could be used in
this
> multi-node partial aggregate pushdown.
Could you please clarify what you mean?
Are you referring to:
  Option 1: Modifying existing aggregate functions to minimize the use of internal state values.
  Option 2: Not supporting the push down of partial aggregates for functions with internal state values.
  Option 3: Something other than Option 1 and Option 2.

There are many aggregate functions with internal state values, so if we go with Option 1,
we might need to change a lot of existing code, like transition functions and finalize functions.
Also, I'm not sure how many existing aggregate functions can be modified this way.

There are also many popular functions with internal state values,
like sum(int8) and avg(int8)(see [1]), so I don't think Option2 would be acceptable.

Best regards, Yuki Fujii

--
Yuki Fujii
Information Technology R&D Center, Mitsubishi Electric Corporation

[1] https://github.com/postgres/postgres/blob/REL_16_STABLE/src/include/catalog/pg_aggregate.dat

pgsql-hackers by date:

Previous
From: Dilip Kumar
Date:
Subject: Re: Logical Replication of sequences
Next
From: Amit Kapila
Date:
Subject: Re: Conflict Detection and Resolution