diff options
| author | Tom Lane <tgl@sss.pgh.pa.us> | 2010-02-19 21:49:10 +0000 |
|---|---|---|
| committer | Tom Lane <tgl@sss.pgh.pa.us> | 2010-02-19 21:49:10 +0000 |
| commit | 3f56ca1d4985bd61af329474a3c654a1eb360c47 (patch) | |
| tree | c573335683b83d6ed5d2baa97d0ea36bf605f650 /src/backend/optimizer/plan/createplan.c | |
| parent | 2f6cf9192c81c5aeb0074ffeb02e5679da0dfc88 (diff) | |
| download | postgresql-3f56ca1d4985bd61af329474a3c654a1eb360c47.tar.gz postgresql-3f56ca1d4985bd61af329474a3c654a1eb360c47.zip | |
Reduce the rescan cost estimate for Materialize nodes to cpu_operator_cost per
tuple, instead of the former cpu_tuple_cost. It is sane to charge less than
cpu_tuple_cost because Materialize never does any qual-checking or projection,
so it's got less overhead than most plan node types. In particular, we want
to have the same charge here as is charged for readout in cost_sort. That
avoids the problem recently exhibited by Teodor wherein the planner prefers
a useless sort over a materialize step in a context where a lot of rescanning
will happen. The rescan costs should be just about the same for both node
types, so make their estimates the same.
Not back-patching because all of the current logic for rescan cost estimates
is new in 9.0. The old handling of rescans is sufficiently not-sane that
changing this in that structure is a bit pointless, and might indeed cause
regressions.
Diffstat (limited to 'src/backend/optimizer/plan/createplan.c')
| -rw-r--r-- | src/backend/optimizer/plan/createplan.c | 8 |
1 files changed, 4 insertions, 4 deletions
diff --git a/src/backend/optimizer/plan/createplan.c b/src/backend/optimizer/plan/createplan.c index 112c2389d11..5c35f77ec2d 100644 --- a/src/backend/optimizer/plan/createplan.c +++ b/src/backend/optimizer/plan/createplan.c @@ -10,7 +10,7 @@ * * * IDENTIFICATION - * $PostgreSQL: pgsql/src/backend/optimizer/plan/createplan.c,v 1.271 2010/02/12 17:33:20 tgl Exp $ + * $PostgreSQL: pgsql/src/backend/optimizer/plan/createplan.c,v 1.272 2010/02/19 21:49:10 tgl Exp $ * *------------------------------------------------------------------------- */ @@ -1703,11 +1703,11 @@ create_mergejoin_plan(PlannerInfo *root, /* * We assume the materialize will not spill to disk, and therefore - * charge just cpu_tuple_cost per tuple. (Keep this estimate in sync - * with cost_mergejoin.) + * charge just cpu_operator_cost per tuple. (Keep this estimate in + * sync with cost_mergejoin.) */ copy_plan_costsize(matplan, inner_plan); - matplan->total_cost += cpu_tuple_cost * matplan->plan_rows; + matplan->total_cost += cpu_operator_cost * matplan->plan_rows; inner_plan = matplan; } |