Re: Proposal: "query_work_mem" GUC, to distribute working memory to the query's individual operators

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