Open andygrove opened 1 month ago
Maybe we could consider moving more of the physical expr implementations into ScalarUDFImpl
user defined functions rather than extending more built in code 🤔
I just discovered that we have this for logical expressions, related to this discussion:
/// Returns true if some of this `exprs` subexpressions may not be evaluated
/// and thus any side effects (like divide by zero) may not be encountered
pub fn short_circuits(&self) -> bool {
Also in ScalarUDFImpl
trait:
/// Returns true if some of this `exprs` subexpressions may not be evaluated
/// and thus any side effects (like divide by zero) may not be encountered
/// Setting this to true prevents certain optimizations such as common subexpression elimination
fn short_circuits(&self) -> bool {
false
}
Is your feature request related to a problem or challenge?
For expressions such as
IF(predicate, true_expr, false_expr)
orCASE WHEN predicate THEN true_expr ELSE false_expr END
, we generally have to be careful to only evaluate thetrue_expr
against rows where thepredicate
evaluated to true.However, if we know that
true_expr
has no side effects (such as throwing exceptions on invalid inputs) and is inexpensive to compute, then we have the option of evaluating it for all rows instead, which can be considerably cheaper in some cases.There is currently no way to determine if a
PhysicalExpr
has side effects. I would like to discuss adding a new method to the trait with a default implementation. Something likeDescribe the solution you'd like
No response
Describe alternatives you've considered
No response
Additional context
No response