Re: Should work_mem be stable for a prepared statement?

> 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.

hmm, if work_mem influences the plan, can we really avoid re-planning?
Here is an example where re-plannning is required to yield a plan
that is based on the current work_mem. right?

postgres=# show work_mem ;
work_mem
----------
4MB
(1 row)

postgres=# prepare sortprep as select * from pg_class order by oid ;
PREPARE
postgres=# explain execute sortprep;
QUERY PLAN
-------------------------------------------------------------------
Sort (cost=36.20..37.23 rows=415 width=273)
Sort Key: oid
-> Seq Scan on pg_class (cost=0.00..18.15 rows=415 width=273)
(3 rows)

postgres=# set work_mem = "64kB";
SET
postgres=# explain execute sortprep;
QUERY PLAN
-------------------------------------------------------------------
Sort (cost=36.20..37.23 rows=415 width=273)
Sort Key: oid
-> Seq Scan on pg_class (cost=0.00..18.15 rows=415 width=273)
(3 rows)

postgres=# explain select * from pg_class order by oid ;
QUERY PLAN
----------------------------------------------------------------------------------------
Index Scan using pg_class_oid_index on pg_class (cost=0.27..60.85
rows=415 width=273)
(1 row)

--

Sami