pgsql: Revise parameterized-path mechanism to fix assorted issues. - Mailing list pgsql-committers
| From | Tom Lane |
|---|---|
| Subject | pgsql: Revise parameterized-path mechanism to fix assorted issues. |
| Date | |
| Msg-id | E1SKxQd-0004Ha-84@gemulon.postgresql.org Whole thread Raw |
| List | pgsql-committers |
Revise parameterized-path mechanism to fix assorted issues. This patch adjusts the treatment of parameterized paths so that all paths with the same parameterization (same set of required outer rels) for the same relation will have the same rowcount estimate. We cache the rowcount estimates to ensure that property, and hopefully save a few cycles too. Doing this makes it practical for add_path_precheck to operate without a rowcount estimate: it need only assume that paths with different parameterizations never dominate each other, which is close enough to true anyway for coarse filtering, because normally a more-parameterized path should yield fewer rows thanks to having more join clauses to apply. In add_path, we do the full nine yards of comparing rowcount estimates along with everything else, so that we can discard parameterized paths that don't actually have an advantage. This fixes some issues I'd found with add_path rejecting parameterized paths on the grounds that they were more expensive than not-parameterized ones, even though they yielded many fewer rows and hence would be cheaper once subsequent joining was considered. To make the same-rowcounts assumption valid, we have to require that any parameterized path enforce *all* join clauses that could be obtained from the particular set of outer rels, even if not all of them are useful for indexing. This is required at both base scans and joins. It's a good thing anyway since the net impact is that join quals are checked at the lowest practical level in the join tree. Hence, discard the original rather ad-hoc mechanism for choosing parameterization joinquals, and build a better one that has a more principled rule for when clauses can be moved. The original rule was actually buggy anyway for lack of knowledge about which relations are part of an outer join's outer side; getting this right requires adding an outer_relids field to RestrictInfo. Branch ------ master Details ------- http://git.postgresql.org/pg/commitdiff/5b7b5518d0ea56c422a197875f7efa5deddbb388 Modified Files -------------- contrib/file_fdw/file_fdw.c | 1 - src/backend/nodes/copyfuncs.c | 1 + src/backend/nodes/equalfuncs.c | 1 + src/backend/nodes/outfuncs.c | 25 ++- src/backend/optimizer/README | 42 ++- src/backend/optimizer/path/allpaths.c | 94 ++++--- src/backend/optimizer/path/costsize.c | 393 ++++++++++++++--------- src/backend/optimizer/path/equivclass.c | 218 +++++++++---- src/backend/optimizer/path/indxpath.c | 146 +++++---- src/backend/optimizer/path/joinpath.c | 6 +- src/backend/optimizer/path/joinrels.c | 2 +- src/backend/optimizer/path/orindxpath.c | 21 +- src/backend/optimizer/path/pathkeys.c | 4 +- src/backend/optimizer/plan/createplan.c | 243 +++++++++----- src/backend/optimizer/plan/initsplan.c | 2 + src/backend/optimizer/plan/planner.c | 2 +- src/backend/optimizer/prep/prepunion.c | 3 + src/backend/optimizer/util/pathnode.c | 487 ++++++++++++++++------------- src/backend/optimizer/util/relnode.c | 300 ++++++++++++++++++- src/backend/optimizer/util/restrictinfo.c | 161 ++++++---- src/include/nodes/nodes.h | 1 + src/include/nodes/relation.h | 87 ++++-- src/include/optimizer/cost.h | 16 +- src/include/optimizer/pathnode.h | 33 ++- src/include/optimizer/paths.h | 5 +- src/include/optimizer/restrictinfo.h | 9 +- src/test/regress/expected/inherit.out | 70 ++++ src/test/regress/expected/join.out | 117 +++++++- src/test/regress/sql/inherit.sql | 31 ++ src/test/regress/sql/join.sql | 42 +++ 30 files changed, 1787 insertions(+), 776 deletions(-)
pgsql-committers by date: