pepijnve commented on code in PR #17973:
URL: https://github.com/apache/datafusion/pull/17973#discussion_r2421383304
##########
datafusion/physical-expr/src/expressions/case.rs:
##########
@@ -431,6 +428,15 @@ impl CaseExpr {
_ => Cow::Owned(prep_null_mask_filter(when_value)),
};
+ let true_count = when_value.true_count();
+ if true_count == batch.num_rows() {
+ // Avoid evaluate_selection when all rows are true
+ return self.when_then_expr[0].1.evaluate(batch);
+ } else if true_count == 0 {
+ // Avoid evaluate_selection when all rows are false/null
+ return self.else_expr.as_ref().unwrap().evaluate(batch);
+ }
+
Review Comment:
> Now that evaluate_selection is changed, do we need those lines here?
@findepi Yes I would prefer to keep these early outs since they're pretty
trivial and I think they're appropriate for the `expr_or_expr` function since
the knowledge that it's "then or else" is located here. `evaluate_selection`
cannot be implemented with awareness of this particular usage pattern.
Calling evaluate_selection still has to produce a value –it can't return
None– so you pay at least a non-zero cost for calling it unnecessarily. If it's
obvious that it will not perform any useful work, it makes sense to avoid it
IMO.
Just for context, the queries I'm working on are quite case heavy. Any work
we can save in the inner loop of the queries seems worthwhile.
--
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: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
