spark-reviews mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From hvanhovell <>
Subject [GitHub] spark pull request #16046: [SPARK-18582][SQL] Whitelist LogicalPlan operator...
Date Thu, 01 Dec 2016 19:39:16 GMT
Github user hvanhovell commented on a diff in the pull request:
    --- Diff: sql/catalyst/src/main/scala/org/apache/spark/sql/catalyst/analysis/Analyzer.scala
    @@ -1120,47 +1173,54 @@ class Analyzer(
               } else {
    -        case w : Window =>
    -          failOnOuterReference(w)
    -          failOnNonEqualCorrelatedPredicate(foundNonEqualCorrelatedPred, w)
    -          w
    -        case j @ Join(left, _, RightOuter, _) =>
    -          failOnOuterReference(j)
    -          failOnOuterReferenceInSubTree(left, "a RIGHT OUTER JOIN")
    -          j
    -        // SPARK-18578: Do not allow any correlated predicate
    -        // in a Full (Outer) Join operator and its descendants
    -        case j @ Join(_, _, FullOuter, _) =>
    -          failOnOuterReferenceInSubTree(j, "a FULL OUTER JOIN")
    -          j
    -        case j @ Join(_, right, jt, _) if !jt.isInstanceOf[InnerLike] =>
    -          failOnOuterReference(j)
    -          failOnOuterReferenceInSubTree(right, "a LEFT (OUTER) JOIN")
    +        // Join can host correlated expressions.
    +        case j @ Join(left, right, joinType, _) =>
    +          joinType match {
    +            // Inner join, like Filter, can be anywhere.
    +            // LeftSemi is a special case of Inner join which returns
    +            // only the first matched row to the right table.
    +            case _: InnerLike | LeftSemi =>
    --- End diff --
    It makes sense to extract predicates from the right hand side of a `LeftSemi` join. My
problem with this is far more practical. `Join` with a `LeftSemi` join type does not output
any right hand side attributes (see:,
the plan **breaks** are as soon as you extract a correlated predicate from the right hand
side of the join and try to rewrite the tree using that predicate. That is all.
    It would - fortunately - be quite simple to support this. Just rewrite every LeftSemi
join with underlying predicates into an Inner join. I am not entirely sure if we should support
this, technically the query is incorrect. Lets defer this to a follow-up PR.
    The example you give is different. I do think we should support that. Please note that
the example you give will not have any left semi joins during analysis, the left semi joins
are introduced during optimization; this makes it relatively straight forward to detect such
a nested case.

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

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message