On Tue, Feb 11, 2025 at 10:00 AM Jeff Davis <pg...@j-davis.com> wrote: > > On Mon, 2025-02-10 at 19:09 -0800, James Hunter wrote: > > I think it makes sense to split the work into two parts: one part > > that > > improves SQL execution, and a second part that improves the > > optimizer, > > to reflect the improvements to execution. > > I like the idea to store the value of work_mem in the > path/plan/executor nodes, and use that at execution time rather than > the GUC directly. > > IIUC, that would allow an extension to do what you want, right? A > planner hook could just walk the tree and edit those values for > individual nodes, and the executor would enforce them.
Yes, exactly! * The Path would store "nbytes" (= the optimizer's estimate of how much working memory a given Path will use), to allow for future optimizer logic to consider memory usage when choosing the best Path. * The Plan would store a copy of "nbytes," along with "work_mem," and the executor would enforce work_mem. A "(work_mem on)" option to the "EXPLAIN" command would display both "nbytes" and "work_mem", per Plan node. * Either built-in logic or an extensibility hook would set "work_mem" on each individual Plan node, based on whatever heuristic or rule it chooses. Right now, my prototype sets "work_mem" inside ExecInitNode(). Thanks, James
