From: | Andrei Lepikhov <lepihov(at)gmail(dot)com> |
---|---|
To: | Jeff Davis <pgsql(at)j-davis(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Organize working memory under per-PlanState context |
Date: | 2025-08-20 07:33:12 |
Message-ID: | 941b6bfc-6760-4fa6-9f24-4f7f2b44dbad@gmail.com |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 20/8/2025 01:34, Jeff Davis wrote:
> 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.Does this mean that you are considering flexible memory allocation
during execution based on a specific memory quota? If so, I believe this
should be taken into account during the optimisation stage. If the
planner calculates the cost of the nodes using only a single work_mem
value, it could lead to suboptimal execution. For example, this might
result in too many intermediate results being written to disk, which in
turn can reduce correlation between the estimated plan cost and the
actual execution time.
--
regards, Andrei Lepikhov
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2025-08-20 07:40:21 | Re: Remove traces of long in dynahash.c |
Previous Message | Andrei Lepikhov | 2025-08-20 07:22:38 | Re: Organize working memory under per-PlanState context |