I can't think of a good reason why JoinCommuteRule doesn't swap outer joins. It would need to flip LEFT -> RIGHT etc. Run through the test suite and see what happens.
Regarding which side of a hash-join is the build side and the probe side. Like Phoenix hash join, EnumerableJoin originally built the left, probed the right, and therefore had a smaller cost if the smaller input were on the left. But we changed it, because the convention in the optimizer world is to build left-deep trees, with the largest input on the left, and smaller, hopefully selective, inputs on the right. The heuristic join ordering rule follows this convention. I think you'll encounter fewer problems in the long run if you swap over to the same convention. Maybe you can achieve it with a quick hack like introducing a project just before you implement. On Fri, Mar 20, 2015 at 12:10 PM, Maryann Xue <[email protected]> wrote: > Hi Julian, > > Noticed that JoinCommuteRule does not swap outer joins by default. Is there > any specific reason to avoid swapping outer joins? And is there a way to > enable swapping outer joins? > > Phoenix hash join output columns from left to right, so we prefer left > outer join over right outer join if hash is possible. So unlike > EnumerableJoin, PhoenixJoin assigns the left hand side with a lower cost > than the right hand side when hashjoin is doable. > > > > Thanks, > Maryann
