diff options
| author | Tom Lane | 2009-09-12 22:12:09 +0000 |
|---|---|---|
| committer | Tom Lane | 2009-09-12 22:12:09 +0000 |
| commit | 9bb342811bf6a93a574a648c5848feedbaaef8f2 (patch) | |
| tree | ecc60f3017cc58695c4c96ebf6d11669e3de6900 /src/backend/optimizer/util/pathnode.c | |
| parent | 5f1b32ddf826550d65dd6e84b965b6a98589ad19 (diff) | |
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.
Diffstat (limited to 'src/backend/optimizer/util/pathnode.c')
| -rw-r--r-- | src/backend/optimizer/util/pathnode.c | 6 |
1 files changed, 4 insertions, 2 deletions
diff --git a/src/backend/optimizer/util/pathnode.c b/src/backend/optimizer/util/pathnode.c index b0358cb112e..e2de24956a2 100644 --- a/src/backend/optimizer/util/pathnode.c +++ b/src/backend/optimizer/util/pathnode.c @@ -8,7 +8,7 @@ * * * IDENTIFICATION - * $PostgreSQL: pgsql/src/backend/optimizer/util/pathnode.c,v 1.152 2009/06/11 14:48:59 momjian Exp $ + * $PostgreSQL: pgsql/src/backend/optimizer/util/pathnode.c,v 1.153 2009/09/12 22:12:04 tgl Exp $ * *------------------------------------------------------------------------- */ @@ -711,6 +711,7 @@ create_material_path(RelOptInfo *rel, Path *subpath) pathnode->subpath = subpath; cost_material(&pathnode->path, + subpath->startup_cost, subpath->total_cost, rel->rows, rel->width); @@ -1424,7 +1425,8 @@ create_mergejoin_path(PlannerInfo *root, * cost_mergejoin will avoid choosing anyway). Therefore * cost_material's cost estimate is bogus and we should charge just * cpu_tuple_cost per tuple. (Keep this estimate in sync with similar - * ones in cost_mergejoin and create_mergejoin_plan.) + * ones in cost_mergejoin and create_mergejoin_plan; also see + * cost_rescan.) */ mpath->startup_cost = inner_path->startup_cost; mpath->total_cost = inner_path->total_cost; |