Re: Eager aggregation, take 3 - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Eager aggregation, take 3
Date
Msg-id CA+TgmoaY6E5-UFTWp5BtAjBO=tDQd=UVAgeJ3dRbFFzhnP5NHg@mail.gmail.com
Whole thread Raw
In response to Re: Eager aggregation, take 3  (Richard Guo <guofenglinux@gmail.com>)
Responses Re: Eager aggregation, take 3
List pgsql-hackers
On Fri, Sep 12, 2025 at 5:34 AM Richard Guo <guofenglinux@gmail.com> wrote:
> I really like this idea.  Currently, aggtransspace represents an
> estimate of the transition state size provided by the aggregate
> definition.  If it's set to zero, a default estimate based on the
> state data type is used.  Negative values currently have no defined
> meaning.  I think it makes perfect sense to reuse this field so that
> a negative value indicates that the transition state data can grow
> unboundedly in size.
>
> Attached 0002 implements this idea.  It requires fewer code changes
> than I expected.  This is mainly because that our current code uses
> aggtransspace in such a way that if it's a positive value, that value
> is used as it's provided by the aggregate definition; otherwise, some
> heuristics are applied to estimate the size.  For the aggregates that
> accumulate input rows (e.g., array_agg, string_agg), I don't currently
> have a better heuristic for estimating their size, so I've chosen to
> keep the current logic.  This won't regress anything in estimating
> transition state data size.

This might be OK, but it's not what I was suggesting: I was suggesting
trying to do a calculation like space_used = -aggtransspace *
rowcount, not just using a <0 value as a sentinel.

--
Robert Haas
EDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: pg_waldump: support decoding of WAL inside tarfile
Next
From: "Chiranmoy.Bhattacharya@fujitsu.com"
Date:
Subject: Re: [PATCH] Hex-coding optimizations using SVE on ARM.