-
Notifications
You must be signed in to change notification settings - Fork 28.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[WIP][SPARK-31919][SQL] Push down more predicates through Join #28741
[WIP][SPARK-31919][SQL] Push down more predicates through Join #28741
Conversation
I will add more test cases. |
|
||
def apply(plan: LogicalPlan): LogicalPlan = plan transform applyLocally | ||
|
||
val applyLocally: PartialFunction[LogicalPlan, LogicalPlan] = { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This method is copied from the original one, except that the join condition is not changed when enablePushingExtraPredicates
is true
Test build #123587 has finished for PR 28741 at commit
|
Just to check; it seems this PR doesn't depend on CNF conversion, but we could get the totally same performance gains with #28733? |
import org.apache.spark.sql.catalyst.rules.Rule | ||
|
||
trait PushPredicateThroughJoinBase extends Rule[LogicalPlan] with PredicateHelper { | ||
protected def enablePushingExtraPredicates: Boolean |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why did you split PushPredicateThroughJoinBase
into the two rules? You couldn't realize this optimization in a single rule?
// if we do not understand what the parent filters are. | ||
// | ||
// Here is an example used to explain the reason. | ||
// Let's say we have NOT(a = 2 AND b in ('1')) and we do not understand how to |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: How about the case, NOT(a = 2 OR b in ('1'))
? This case can be transformed into NOT(a = 2) AND NOT(b in ('1'))
then I think it can be partially pushed down.
It seems this solution cannot be fully optimized.
After this PR(
|
@wangyum Thanks for point it out. |
What changes were proposed in this pull request?
Currently, in the rule
PushPredicateThroughJoin
, if the condition predicate ofOr
operator can't be entirely pushed down, it will be thrown away.In fact, the predicates under
Or
operators can be partially pushed down.For example, says
a
andb
are able to be pushed into one of the joined tables, whilec
can't be pushed down, the predicatea or (b and c)
can be converted as
(a or b) and (a or c)
We can still push down
(a or b)
.We can't push down disjunctive predicates only when one of its children is not partially convertible.
The common way is to convert the condition into conjunctive normal form(CNF), so that we can find all the predicates that can be pushed down by going over the CNF predicate.
However, CNF conversion result can be huge, the recursive implementation can cause stack overflow on complex predicates. There were PRs for it such as #10444, #15558, #28575.
There is also non-recursive implementation: #28733 . It should be workable but this PR proposes a simpler implementation.
Essentially, we just need to traverse predicate and extract the convertible sub-predicates like what we did in #24598 . There is no need to maintain the CNF result set.
Why are the changes needed?
Improve query performance. PostgreSQL, Impala and Hive support similiar feature.
Does this PR introduce any user-facing change?
No
How was this patch tested?
Unit test and benchmark test.