Thread: pgsql: Fix best_inner_indexscan to return both the cheapest-total-cost
pgsql: Fix best_inner_indexscan to return both the cheapest-total-cost
From
tgl@postgresql.org (Tom Lane)
Date:
Log Message: ----------- Fix best_inner_indexscan to return both the cheapest-total-cost and cheapest-startup-cost innerjoin indexscans, and make joinpath.c consider both of these (when different) as the inside of a nestloop join. The original design was based on the assumption that indexscan paths always have negligible startup cost, and so total cost is the only important figure of merit; an assumption that's obviously broken by bitmap indexscans. This oversight could lead to choosing poor plans in cases where fast-start behavior is more important than total cost, such as LIMIT and IN queries. 8.1-vintage brain fade exposed by an example from Chuck D. Tags: ---- REL8_1_STABLE Modified Files: -------------- pgsql/src/backend/nodes: outfuncs.c (r1.261.2.1 -> r1.261.2.2) (http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/nodes/outfuncs.c.diff?r1=1.261.2.1&r2=1.261.2.2) pgsql/src/backend/optimizer/path: indxpath.c (r1.191.2.10 -> r1.191.2.11) (http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/optimizer/path/indxpath.c.diff?r1=1.191.2.10&r2=1.191.2.11) joinpath.c (r1.97.2.1 -> r1.97.2.2) (http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/optimizer/path/joinpath.c.diff?r1=1.97.2.1&r2=1.97.2.2) pgsql/src/include/nodes: relation.h (r1.119.2.1 -> r1.119.2.2) (http://developer.postgresql.org/cvsweb.cgi/pgsql/src/include/nodes/relation.h.diff?r1=1.119.2.1&r2=1.119.2.2) pgsql/src/include/optimizer: paths.h (r1.88.2.2 -> r1.88.2.3) (http://developer.postgresql.org/cvsweb.cgi/pgsql/src/include/optimizer/paths.h.diff?r1=1.88.2.2&r2=1.88.2.3)