DhamoPS commented on code in PR #3334:
URL: https://github.com/apache/arrow-datafusion/pull/3334#discussion_r961826137
##########
datafusion/sql/src/planner.rs:
##########
@@ -2453,6 +2453,17 @@ fn remove_join_expressions(
(_, Some(rr)) => Ok(Some(rr)),
_ => Ok(None),
}
+ },
+ // Fix for issue#78 join predicates from inside of OR expr also
pulled up properly.
+ Operator::Or => {
Review Comment:
yes, I agree that OR predicates need to be handled differently.
OR predicates are handled in below code.
` Operator::Or => {
let mut left_join_keys = vec![];
let mut right_join_keys = vec![];
extract_possible_join_keys(left, &mut left_join_keys)?;
extract_possible_join_keys(right, &mut right_join_keys)?;
intersect( accum, &left_join_keys, &right_join_keys)
}`
In case of OR predicates, we pull the predicates if both left and right
child are having same JOIN predicates.
insect() function would ensure that we don't pull the all OR predicates.
In the example given above, `l.partkey=s.partkey or l.price < 5.00`, the
left child of OR predicate would be `l.partkey=s.partkey` and right child of OR
predicate would be ` l.price < 5.00'. There is no common predicates on left and
right child of OR expr and so these predicates are not pulled to Join
Predicates.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: github-unsubscr...@arrow.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
