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

From: Jeff Davis <pgsql(at)j-davis(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Scott Carey <scott(dot)carey(at)algonomy(dot)com>
Cc: David Rowley <dgrowleyml(at)gmail(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-03 19:24:49
Message-ID: d7e2f7606818c629dbc684575a6c32a2045e0209.camel@j-davis.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-performance

On Thu, 2026-04-02 at 18:03 -0400, Tom Lane wrote:

> and a secondary problem is that that drives the
> cost of hash_agg_check_limits to an unacceptable level.

I recall some discussion about whether the memory accounting would
recurse to child contexts at the time MemoryContextGetMemAllocated() is
called, or whether it would update the parent contexts at the time a
new block is allocated in a subcontext. Using the latter strategy would
solve the high cost when there are many subcontexts.

Regards,
Jeff Davis

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Jeff Davis 2026-04-03 19:36:23 Re: Significant performance issues with array_agg() + HashAggregate plans on Postgres 17
Previous Message Tom Lane 2026-04-03 19:24:15 Re: Significant performance issues with array_agg() + HashAggregate plans on Postgres 17