Horton
Menu

Re: Significant performance issues with array_agg() + HashAggregate plans on Postgres 17

David Rowley <dgrowleyml@gmail.com>

View thread
From: David Rowley <dgrowleyml@gmail.com>
To: Tomas Vondra <tomas@vondra.me>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Jeff Davis <pgsql@j-davis.com>, Scott Carey <scott.carey@algonomy.com>, pgsql-performance@lists.postgresql.org
Date: 2026-04-11T02:09:45Z
Lists: 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

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Disk-based Hash Aggregation.