Rewrite the planner's handling of materialized plan types so that there is
authorTom Lane <tgl@sss.pgh.pa.us>
Sat, 12 Sep 2009 22:12:09 +0000 (22:12 +0000)
committerTom Lane <tgl@sss.pgh.pa.us>
Sat, 12 Sep 2009 22:12:09 +0000 (22:12 +0000)
commit80e7c390ef888bbae81a522acac0a0a33bc32b10
tree854d87643394d348136afcd285754b523fc57299
parenta52be7c55da75b7105c5c76b38028baf68e20026
Rewrite the planner's handling of materialized plan types so that there is
an explicit model of rescan costs being different from first-time costs.
The costing of Material nodes in particular now has some visible relationship
to the actual runtime behavior, where before it was essentially fantasy.
This also fixes up a couple of places where different materialized plan types
were treated differently for no very good reason (probably just oversights).

A couple of the regression tests are affected, because the planner now chooses
to put the other relation on the inside of a nestloop-with-materialize.
So far as I can see both changes are sane, and the planner is now more
consistently following the expectation that it should prefer to materialize
the smaller of two relations.

Per a recent discussion with Robert Haas.
12 files changed:
src/backend/executor/execAmi.c
src/backend/optimizer/path/costsize.c
src/backend/optimizer/path/joinpath.c
src/backend/optimizer/plan/createplan.c
src/backend/optimizer/plan/subselect.c
src/backend/optimizer/util/pathnode.c
src/include/executor/executor.h
src/include/optimizer/cost.h
src/test/regress/expected/geometry.out
src/test/regress/expected/geometry_1.out
src/test/regress/expected/geometry_2.out
src/test/regress/expected/join.out