On Fri, 28 Feb 2025 at 07:42, Jeff Davis <pg...@j-davis.com> wrote: > https://www.postgresql.org/message-id/CAJVSvF6s1LgXF6KB2Cz68sHzk%2Bv%2BO_vmwEkaon%3DH8O9VcOr-tQ%40mail.gmail.com > > James pointed out something interesting, which is that a prepared > statement enforces the work_mem limit at execution time, which might be > different from the work_mem at the time the statement was prepared.
There's a similar but not quite the same situation with the enable_* GUCs. The executor isn't going to pick up a new value for these like it will for work_mem, but I think portions of the same argument can be made, i.e. Someone might not like that turning off enable_seqscan after doing PREPARE and EXECUTE once does not invalidate their plan. > My first reaction is that it's not right because the costing for the > plan is completely bogus with a different work_mem. It would make more > sense to me if we either (a) enforced work_mem as it was at the time of > planning; or (b) replanned if executed with a different work_mem > (similar to how we replan sometimes with different parameters). If we were to fix this then a) effectively already happens for the enable_* GUCs, so b) would be the only logical way to fix. > But I'm not sure whether someone might be relying on the existing > behavior? It looks like there was a bit of discussion on this topic about 18 years ago in [1], but it didn't seem to end with a very conclusive outcome. I did learn that we once didn't have a method to invalidate cached plans, so perhaps the current behaviour is a remnant of the previous lack of infrastructure. David [1] https://www.postgresql.org/message-id/15168.1174410673%40sss.pgh.pa.us
