Further fixes for degenerate outer join clauses.
Further testing revealed that commit f69b4b94 was still a few bricks shy of a load: minor tweaking of the previous test cases resulted in the same wrong-outer-join-order problem coming back. After study I concluded that my previous changes in make_outerjoininfo() were just accidentally masking the problem, and should be reverted in favor of forcing syntactic join order whenever an upper outer join's predicate doesn't mention a lower outer join's LHS. This still allows the chained-outer-joins style that is the normally optimizable case. I also tightened things up some more in join_is_legal(). It seems to me on review that what's really happening in the exception case where we ignore a mismatched special join is that we're allowing the proposed join to associate into the RHS of the outer join we're comparing it to. As such, we should *always* insist that the proposed join be a left join, which eliminates a bunch of rather dubious argumentation. The case where we weren't enforcing that was the one that was already known buggy anyway (it had a violatable Assert before the aforesaid commit) so it hardly deserves a lot of deference. Back-patch to all active branches, like the previous patch. The added regression test case failed in all branches back to 9.1, and I think it's only an unrelated change in costing calculations that kept 9.0 from choosing a broken plan.
Showing
- src/backend/optimizer/README 17 additions, 6 deletionssrc/backend/optimizer/README
- src/backend/optimizer/path/joinrels.c 27 additions, 46 deletionssrc/backend/optimizer/path/joinrels.c
- src/backend/optimizer/plan/initsplan.c 13 additions, 15 deletionssrc/backend/optimizer/plan/initsplan.c
- src/test/regress/expected/join.out 71 additions, 1 deletionsrc/test/regress/expected/join.out
- src/test/regress/sql/join.sql 25 additions, 0 deletionssrc/test/regress/sql/join.sql
Loading
Please register or sign in to comment