From: | Jeff Davis <pgsql(at)j-davis(dot)com> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Organize working memory under per-PlanState context |
Date: | 2025-08-19 23:34:24 |
Message-ID: | 2d815d152175d29cc69890964adc599ca4672d01.camel@j-davis.com |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Right now, the work_mem limit is tracked and enforced ad-hoc throughout
the executor. Different nodes tally the total memory usage differently,
may use different internal data structures (each of which can consume
work_mem independently), and decide when to spill based on different
criteria, etc.
Note: this is *not* an attempt to manage the memory usage across an
entire query. This is just about memory usage within a single executor
node.
The attached proof-of-concept patch adds a MemoryContext field
ps_WorkMem to PlanState, and nodes that care about it initialize it
with GetWorkMem(), and switch to that context as necessary.
It doesn't do much yet, but it creates infrastructure that will be
useful for subsequent patches to make the memory accounting and
enforcement more consistent throughout the executor.
In particular, it uses MemoryContextMemAllocated(), which includes
fragmentation, chunk headers, and free space. In the current code,
fragmentation is ignored most places, so (for example) switching to the
Bump allocator doesn't show the savings.
This isn't ready yet, but I'd appreciate some thoughts on the overall
architectural direction.
Regards,
Jeff Davis
Attachment | Content-Type | Size |
---|---|---|
v1-0001-Use-per-PlanState-memory-context-for-work-mem.patch | text/x-patch | 24.8 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Thomas Munro | 2025-08-19 23:59:42 | Re: VM corruption on standby |
Previous Message | Mihail Nikalayeu | 2025-08-19 22:44:00 | Re: [BUG?] check_exclusion_or_unique_constraint false negative |