-
- Downloads
Weaken the planner's tests for relevant joinclauses.
We should be willing to cross-join two small relations if that allows us to use an inner indexscan on a large relation (that is, the potential indexqual for the large table requires both smaller relations). This worked in simple cases but fell apart as soon as there was a join clause to a fourth relation, because the existence of any two-relation join clause caused the planner to not consider clauseless joins between other base relations. The added regression test shows an example case adapted from a recent complaint from Benoit Delbosc. Adjust have_relevant_joinclause, have_relevant_eclass_joinclause, and has_relevant_eclass_joinclause to consider that a join clause mentioning three or more relations is sufficient grounds for joining any subset of those relations, even if we have to do so via a cartesian join. Since such clauses are relatively uncommon, this shouldn't affect planning speed on typical queries; in fact it should help a bit, because the latter two functions in particular get significantly simpler. Although this is arguably a bug fix, I'm not going to risk back-patching it, since it might have currently-unforeseen consequences.
Showing
- src/backend/optimizer/path/equivclass.c 19 additions, 77 deletionssrc/backend/optimizer/path/equivclass.c
- src/backend/optimizer/path/joinrels.c 5 additions, 9 deletionssrc/backend/optimizer/path/joinrels.c
- src/backend/optimizer/util/joininfo.c 17 additions, 7 deletionssrc/backend/optimizer/util/joininfo.c
- src/test/regress/expected/join.out 51 additions, 0 deletionssrc/test/regress/expected/join.out
- src/test/regress/sql/join.sql 18 additions, 0 deletionssrc/test/regress/sql/join.sql
Loading
Please register or sign in to comment