Re: Partial aggregates pushdown - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: Partial aggregates pushdown
Date
Msg-id Z-hyve2DLzBpdDdW@momjian.us
Whole thread Raw
In response to RE: Partial aggregates pushdown  ("Fujii.Yuki@df.MitsubishiElectric.co.jp" <Fujii.Yuki@df.MitsubishiElectric.co.jp>)
List pgsql-hackers
On Fri, Mar 28, 2025 at 02:00:44AM +0000, Fujii.Yuki@df.MitsubishiElectric.co.jp wrote:
> Hi Bruce, Jelte, hackers.
> 
> I apologize for my late response.
> 
> > From: Jelte Fennema-Nio <postgres@jeltef.nl>
> > Sent: Thursday, August 8, 2024 8:49 PM
> > SUMMARY OF THREAD
> > 
> > The design of patch 0001 is agreed upon by everyone on the thread (so far). This adds the PARTIAL_AGGREGATE label
for
> > aggregates, which will cause the finalfunc not to run. It also starts using PARTIAL_AGGREGATE for pushdown of
> > aggregates in postgres_fdw. In 0001 PARTIAL_AGGREGATE is only supported for aggregates with a non-internal/pseudo
> > type as the stype.
> > 
> > The design for patch 0002 is still under debate. This would expand on the functionality added by adding support
for
> > PARTIAL_AGGREGATE for aggregates with an internal stype. This is done by returning a byte array containing the
bytes
> > that the serialfunc of the aggregate returns.
> > 
> > A competing proposal for 0002 is to instead change aggregates to not use an internal stype anymore, and create
dedicated
> > types. The main downside here is that infunc and outfunc would need to be added for text serialization, in addition
tothe
 
> > binary serialization. An open question is: Can we change the requirements for CREATE TYPE, so that types can be
created
> > without infunc and outfunc.
> 
> I rebased the patch 0001 and add the documentation to it.

Okay, this is too late for PG 18 but I am hopeful we can make progress
on this for PG 19.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EDB                                      https://enterprisedb.com

  Do not let urgent matters crowd out time for investment in the future.



pgsql-hackers by date:

Previous
From: Alexander Korotkov
Date:
Subject: Re: Replace IN VALUES with ANY in WHERE clauses during optimization
Next
From: Michael Zhilin
Date:
Subject: [PATCH] Avoid useless prefetches in case of recent FPI WAL records