> 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
