]> granicus.if.org Git - postgresql/commit
Repair logic flaw in cost estimator: cost_nestloop() was estimating CPU
authorTom Lane <tgl@sss.pgh.pa.us>
Wed, 22 Mar 2000 22:08:35 +0000 (22:08 +0000)
committerTom Lane <tgl@sss.pgh.pa.us>
Wed, 22 Mar 2000 22:08:35 +0000 (22:08 +0000)
commit1d5e7a6f46f799628392fc4a024a3d61e3dd1630
tree991172a18881641faae08ec32d986d280d45f602
parentd825e55c1315baeea58a3752b86a2a1c4c77e03c
Repair logic flaw in cost estimator: cost_nestloop() was estimating CPU
costs using the inner path's parent->rows count as the number of tuples
processed per inner scan iteration.  This is wrong when we are using an
inner indexscan with indexquals based on join clauses, because the rows
count in a Relation node reflects the selectivity of the restriction
clauses for that rel only.  Upshot was that if join clause was very
selective, we'd drastically overestimate the true cost of the join.
Fix is to calculate correct output-rows estimate for an inner indexscan
when the IndexPath node is created and save it in the path node.
Change of path node doesn't require initdb, since path nodes don't
appear in saved rules.
src/backend/nodes/copyfuncs.c
src/backend/nodes/equalfuncs.c
src/backend/nodes/outfuncs.c
src/backend/nodes/readfuncs.c
src/backend/optimizer/path/costsize.c
src/backend/optimizer/path/indxpath.c
src/backend/optimizer/path/orindxpath.c
src/backend/optimizer/plan/createplan.c
src/backend/optimizer/util/pathnode.c
src/include/nodes/relation.h
src/include/optimizer/cost.h