mirror of
https://github.com/postgres/postgres.git
synced 2025-07-09 22:41:56 +03:00
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.
This commit is contained in:
@ -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;
|
||||
}
|
||||
|
Reference in New Issue
Block a user