]> granicus.if.org Git - postgresql/commit
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)
commit9bb342811bf6a93a574a648c5848feedbaaef8f2
treeecc60f3017cc58695c4c96ebf6d11669e3de6900
parent5f1b32ddf826550d65dd6e84b965b6a98589ad19
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