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