Re: Should work_mem be stable for a prepared statement?

Sami Imseih <samimseih(at)gmail(dot)com> writes:
> However, I think any GUC that can influence the planner
> should be considered for consistency in behavior.
> It was mentioned above with the enable_* GUCs, but another
> one I can think of is the max_parallel_workers_per_gather which
> should then force a re-plan if changed. I have seen users need to turn
> that off in a hurry when it impacts their oltp workload.

The argument for treating work_mem specially is that it has effects at
both plan time and run time, so that the planner's cost assumptions
are invalidated if the executor uses a different value than the
planner did. I don't believe that argument applies to anything else;
certainly it doesn't apply to the enable_* flags. I'm also not
convinced that the argument requires us to solve the problem by
re-planning. It would work just as well to stamp each PlannedStmt
with the value that the planner used and refer to that in the
executor instead of looking directly at the GUC.

This is all kind of moot though, now that Jeff has revealed that
what he's really interested in is some sort of refactoring.
Maybe that refactoring is one that would conveniently apply to
other GUCs, or maybe it isn't. I'm content to await details
before arguing about what we "should" do.

regards, tom lane