Horton
Menu

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

Jeff Davis <pgsql@j-davis.com>

View thread
From: Jeff Davis <pgsql@j-davis.com>
To: Tom Lane <tgl@sss.pgh.pa.us>, Scott Carey <scott.carey@algonomy.com>
Cc: David Rowley <dgrowleyml@gmail.com>, pgsql-performance@lists.postgresql.org
Date: 2026-04-03T19:24:49Z
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

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.