spark-reviews mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From gatorsmile <...@git.apache.org>
Subject [GitHub] spark pull request #16659: [SPARK-19309][SQL] disable common subexpression e...
Date Sat, 21 Jan 2017 18:18:35 GMT
Github user gatorsmile commented on a diff in the pull request:

    https://github.com/apache/spark/pull/16659#discussion_r97203450
  
    --- 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.
    +    //   4. Coalesce: it's also a conditional expression, we should only recurse into
the first
    +    //                children, because others may not get accessed.
    --- End diff --
    
    Although `Coalesce` might  miss some expression elimination chances, I think it is very
rare when users use the same expressions in  `Coalesce`. 
    
    Could you update the comments?


---
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 infrastructure@apache.org or file a JIRA ticket
with INFRA.
---

---------------------------------------------------------------------
To unsubscribe, e-mail: reviews-unsubscribe@spark.apache.org
For additional commands, e-mail: reviews-help@spark.apache.org


Mime
View raw message