| From: | David Rowley <dgrowleyml(at)gmail(dot)com> |
|---|---|
| To: | Tomas Vondra <tomas(at)vondra(dot)me> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Jeff Davis <pgsql(at)j-davis(dot)com>, Scott Carey <scott(dot)carey(at)algonomy(dot)com>, pgsql-performance(at)lists(dot)postgresql(dot)org |
| Subject: | Re: Significant performance issues with array_agg() + HashAggregate plans on Postgres 17 |
| Date: | 2026-04-11 02:09:45 |
| Message-ID: | CAApHDvpcwJh8_P5jp4Wp-A6HwCPyc=_kEG9RwYpB42ZQX3TK9Q@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
On Sun, 5 Apr 2026 at 01:18, Tomas Vondra <tomas(at)vondra(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | David Rowley | 2026-04-11 02:42:54 | Re: Significant performance issues with array_agg() + HashAggregate plans on Postgres 17 |
| Previous Message | Priya V | 2026-04-09 22:39:06 | Async standby lag + physical slot + hot_standby_feedback=on appeared to degrade primary performance |