Github user gatorsmile commented on a diff in the pull request:
https://github.com/apache/spark/pull/16659#discussion_r97202843
--- Diff:
sql/catalyst/src/main/scala/org/apache/spark/sql/catalyst/expressions/EquivalentExpressions.scala
---
@@ -67,28 +67,33 @@ class EquivalentExpressions {
/**
* Adds the expression to this data structure recursively. Stops if a
matching expression
* is found. That is, if `expr` has already been added, its children are
not added.
- * If ignoreLeaf is true, leaf nodes are ignored.
*/
- def addExprTree(
- root: Expression,
- ignoreLeaf: Boolean = true,
- skipReferenceToExpressions: Boolean = true): Unit = {
- val skip = (root.isInstanceOf[LeafExpression] && ignoreLeaf) ||
+ def addExprTree(expr: Expression): Unit = {
+ val skip = expr.isInstanceOf[LeafExpression] ||
// `LambdaVariable` is usually used as a loop variable, which can't
be evaluated ahead of the
// loop. So we can't evaluate sub-expressions containing
`LambdaVariable` at the beginning.
- root.find(_.isInstanceOf[LambdaVariable]).isDefined
- // There are some special expressions that we should not recurse into
children.
+ expr.find(_.isInstanceOf[LambdaVariable]).isDefined
+
+ // There are some special expressions that we should not recurse into
all of its children.
// 1. CodegenFallback: it's children will not be used to generate
code (call eval() instead)
- // 2. ReferenceToExpressions: it's kind of an explicit
sub-expression elimination.
- val shouldRecurse = root match {
- // TODO: some expressions implements `CodegenFallback` but can still
do codegen,
- // e.g. `CaseWhen`, we should support them.
- case _: CodegenFallback => false
- case _: ReferenceToExpressions if skipReferenceToExpressions => false
- case _ => true
+ // 2. If: common subexpressions will always be evaluated at the
beginning, but the true and
+ // false expressions in `If` may not get accessed, according
to the predicate
+ // expression. We should only recurse into the predicate
expression.
+ // 3. CaseWhen: like `If`, the children of `CaseWhen` only get
accessed in a certain
+ // condition. We should only recurse into the first
condition expression as it
+ // will always get accessed.
--- End diff --
`CaseWhen` could be very deep.
> CASE WHEN expr1 THEN expr2 [WHEN expr3 THEN expr4]* [ELSE expr5] END
> When `expr1` = true, returns `expr2`; when `expr3` = true, return
`expr4`; else return `expr5`.
Compared with the previous impl, will we miss some expression elimination
chances?
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at [email protected] or file a JIRA ticket
with INFRA.
---
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]