On Sat, 2026-10-03 at 19:46 -0300, Manu wrote: > Each Plan node gets a workmem field...The executor uses the node's > value...I first tried copying work_mem into the field at plan time. > Then SET > LOCAL work_mem inside a PL/pgSQL function no longer reached a query > whose plan was already cached: it wrote a 13 MB temporary file that > master does not. Replanning cached plans when work_mem changes fixes > that, but cost 47% of the tps in a pgbench run that changes work_mem > in > every transaction before a prepared 3-way join.
Regarding the previous discussion here: https://www.postgresql.org/message-id/2a2b28e2ea677e3cec2850b2dd38b467bf1291fb.camel%40j-davis.com IIUC, you resolve the issue by introducing a special zero value, which preserves the existing behavior by default, and only an extension can set it to a non-zero value. There's no auto-replan, so using an extension would get behavior (a) described in the above thread. I generally like that approach. It allows some experimentation with planner hooks without changing existing behavior. It also avoids some difficulty transmitting work_mem to places that don't have easy access to the Plan structure. It's essentially a refactor, so the cost is ~200 lines, some code churn, and extra function parameters. I didn't review all the details yet, but if a real extension actually uses this, that seems reasonable to me. Regards, Jeff Davis
