calcite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Julian Hyde <julianh...@gmail.com>
Subject Re: About JoinCommuteRule
Date Fri, 20 Mar 2015 19:28:44 GMT
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 <maryann.xue@gmail.com> 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

Mime
View raw message