Thread: pgsql: Reduce the rescan cost estimate for Materialize nodes to
pgsql: Reduce the rescan cost estimate for Materialize nodes to
From
tgl@postgresql.org (Tom Lane)
Date:
Log Message: ----------- 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. Modified Files: -------------- pgsql/src/backend/optimizer/path: costsize.c (r1.214 -> r1.215) (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/optimizer/path/costsize.c?r1=1.214&r2=1.215) pgsql/src/backend/optimizer/plan: createplan.c (r1.271 -> r1.272) (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/optimizer/plan/createplan.c?r1=1.271&r2=1.272)