From: | tgl(at)postgresql(dot)org (Tom Lane) |
---|---|
To: | pgsql-committers(at)postgresql(dot)org |
Subject: | pgsql: Reduce the rescan cost estimate for Materialize nodes to |
Date: | 2010-02-19 21:49:10 |
Message-ID: | 20100219214910.BCC6B7541C5@cvs.postgresql.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers |
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)
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2010-02-19 23:55:53 | pgsql: Remove incorrect statement that PostgreSQL 8.4 has no default |
Previous Message | Peter Eisentraut | 2010-02-19 18:43:31 | pgsql: Version stamp 9.0alpha4 (in the right branch) |