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

Reply via email to