berkaysynnada commented on code in PR #15462: URL: https://github.com/apache/datafusion/pull/15462#discussion_r2033101460
########## datafusion/physical-expr/src/expressions/binary.rs: ########## @@ -805,6 +811,47 @@ impl BinaryExpr { } } +/// Check if it meets the short-circuit condition +/// 1. For the `AND` operator, if the `lhs` result all are `false` +/// 2. For the `OR` operator, if the `lhs` result all are `true` +/// 3. Otherwise, it does not meet the short-circuit condition +fn check_short_circuit(arg: &ColumnarValue, op: &Operator) -> bool { Review Comment: I think I couldn't be clear in my last comment. This PR short-circuits this case: ``` [false,false,false...false] AND [xxx] => return lhs, which is [false,false,false...false] [true, true, true... true] OR [xxx] => return lhs, which is [true, true, true...true] ``` I have 2 further ideas to discuss: 1) ``` [xxx] AND [false,false,false...false] => return rhs, which is [false,false,false...false] [xxx] OR [true, true, true... true] => return rhs, which is [true, true, true...true] ``` Why don't we check this case as well? 2) ``` [xxx] AND [true, true, true... true] => return lhs, which is [xxx] [xxx] OR [false, false, false... false] => return lhs, which is [xxx] ``` isn't this case optimizable as well? Are we handling those cases in another place? -- 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...@datafusion.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: github-unsubscr...@datafusion.apache.org For additional commands, e-mail: github-h...@datafusion.apache.org