Re: Significant performance issues with array_agg() + HashAggregate plans on Postgres 17
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Jeff Davis <pgsql@j-davis.com>
Cc: Scott Carey <scott.carey@algonomy.com>,
David Rowley <dgrowleyml@gmail.com>,
pgsql-performance@lists.postgresql.org
Date: 2026-04-03T19:56:22Z
Lists: pgsql-performance
Jeff Davis <pgsql@j-davis.com> writes: > One idea would be to update parent contexts' memory totals recursively > each time a subcontext allocates a new block. Block allocations are > infrequent enough that may be acceptable. > If we are worried about affecting unrelated cases, we could set an > "accounting_enabled" flag for the contexts we care about, which would > be automatically inherited by subcontexts, and then stop recursing up > when that flag is false. Yeah, I was speculating about similar ideas. Since mem_allocated is only changed after a malloc() or free() call, it probably wouldn't add too much overhead to propagate that up to parent contexts. I agree with having a flag to prevent the propagation from going up further than we actually care about, though. Would it make sense to accumulate those values in a separate field child_mem_allocated, rather than redefining what mem_allocated means? regards, tom lane
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Disk-based Hash Aggregation.
- 1f39bce02154 13.0 cited