You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When optimising the logical plan if ExtractEquijoinPredicate encounters a join with no existing conditions in the "on" vector and no results for split_eq_and_noneq_join_predicate then do a similar check for "IS NOT DISTINCT FROM". If this returns some conditions then push these into the "on" vector and set null_equals_null to true.
We've got a change like this on our fork of DF. We also had to add a few checks to some optimiser rules to stop them rewriting joins without checking null_equals_null.
Describe alternatives you've considered
I don't know if this could potentially be left to a later optimisation pass.
Additional context
No response
The text was updated successfully, but these errors were encountered:
Is your feature request related to a problem or challenge?
It would be nice if the optimiser could use hash joins when queries contain IS NOT DISTINCT FROM - with null_equals_null behaviour
e.g. as it is at the moment
will use a hash join while
will use a nested loop
below
Describe the solution you'd like
When optimising the logical plan if ExtractEquijoinPredicate encounters a join with no existing conditions in the "on" vector and no results for split_eq_and_noneq_join_predicate then do a similar check for "IS NOT DISTINCT FROM". If this returns some conditions then push these into the "on" vector and set null_equals_null to true.
We've got a change like this on our fork of DF. We also had to add a few checks to some optimiser rules to stop them rewriting joins without checking null_equals_null.
Describe alternatives you've considered
I don't know if this could potentially be left to a later optimisation pass.
Additional context
No response
The text was updated successfully, but these errors were encountered: