leanken commented on pull request #29104:
URL: https://github.com/apache/spark/pull/29104#issuecomment-661664217
> In ExtractEquiJoinKeys (in patterns.scala) there is code like this:
>
> ```
> case EqualTo(l, r) if canEvaluate(l, left) && canEvaluate(r,
right) => Some((l, r))
> case EqualTo(l, r) if canEvaluate(l, right) && canEvaluate(r,
left) => Some((r, l))
> ```
>
> So I am wondering if it is possible that LeftAnti join can actually have
the left side as the build and the right side as streaming ? Is it possible we
won't optimize that case ? Do you think it makes sense to ensure that BNLJ is
not present for any not-in query ? (ie this optimization should kick in always).
>
> I am still a bit surprised that you didn't have to modify any .sql.out
files because the plan would have changed from BNLJ to BHJ.
```
join.scala has restricted rules about left anti join build side
it seems that only InnerLike can support both buildLeft and buildRight
def canBuildLeft(joinType: JoinType): Boolean = {
joinType match {
case _: InnerLike | RightOuter => true
case _ => false
}
}
def canBuildRight(joinType: JoinType): Boolean = {
joinType match {
case _: InnerLike | LeftOuter | LeftSemi | LeftAnti | _: ExistenceJoin
=> true
case _ => false
}
}
```
----------------------------------------------------------------
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.
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
