Re: Significant performance issues with array_agg() + HashAggregate plans on Postgres 17 - Mailing list pgsql-performance

From David Rowley
Subject Re: Significant performance issues with array_agg() + HashAggregate plans on Postgres 17
Date
Msg-id CAApHDvpcwJh8_P5jp4Wp-A6HwCPyc=_kEG9RwYpB42ZQX3TK9Q@mail.gmail.com
Whole thread
In response to Re: Significant performance issues with array_agg() + HashAggregate plans on Postgres 17  (Tomas Vondra <tomas@vondra.me>)
List pgsql-performance
On Sun, 5 Apr 2026 at 01:18, Tomas Vondra <tomas@vondra.me> wrote:
> This reminds me the discussions in 2022 about having a global memory
> limit, and in particular this PoC patch [1] with a MemoryPool doing
> roughly what you're describing here (at least I think).
>
> [1]
> https://www.postgresql.org/message-id/4fb99fb7-8a6a-2828-dd77-e2f1d75c7dd0%40enterprisedb.com

I think the ideas are quite different. I see in that patch you're
raising an ERROR if the memory usage goes over some threshold. What I
had in mind was adding lightweight opt-in infrastructure to allow code
to quickly check how much memory is being consumed by a MemoryContext
and all of its child contexts.

David



pgsql-performance by date:

Previous
From: Priya V
Date:
Subject: Async standby lag + physical slot + hot_standby_feedback=on appeared to degrade primary performance
Next
From: David Rowley
Date:
Subject: Re: Significant performance issues with array_agg() + HashAggregate plans on Postgres 17