Uh oh!
There was an error while loading. Please reload this page.
[SPARK-23172][SQL] Expand the ReorderJoin rule to handle Project nodes - #20345
[SPARK-23172][SQL] Expand the ReorderJoin rule to handle Project nodes#20345maropu wants to merge 3 commits into
Conversation
SparkQA
commented
Jan 21, 2018
Test build #86449 has finished for PR 20345 at commit
|
SparkQA
commented
Jan 22, 2018
Test build #86485 has finished for PR 20345 at commit
|
jiangxb1987
commented
Jan 22, 2018
retest this please |
jiangxb1987
commented
Jan 23, 2018
This is not |
There was a problem hiding this comment.
It took me a little while to understand that this can handle (a join b) join c versus a join (b join c) correctly. Would be great if we can explain how it works in the function comment.
There was a problem hiding this comment.
nit:
def testExtractInnerJoins(
plan: LogicalPlan,
expected: Option[(Seq[(LogicalPlan, InnerLike)], Seq[Expression])]) {
There was a problem hiding this comment.
Won't this ignore the plans sequence?
maropu
commented
Jan 23, 2018
Thanks! @jiangxb1987 I'll address your comments and check again? |
SparkQA
commented
Jan 23, 2018
Test build #86499 has finished for PR 20345 at commit
|
maropu
commented
Jan 23, 2018
retest this please. |
SparkQA
commented
Jan 23, 2018
Test build #86504 has finished for PR 20345 at commit
|
SparkQA
commented
Jan 23, 2018
Test build #86511 has finished for PR 20345 at commit
|
gatorsmile
commented
Jan 27, 2018
Also cc @wzhfy Do you have a bandwidth to review PRs? |
maropu
commented
Mar 6, 2018
ping |
NVM, I understood: |
There was a problem hiding this comment.
If we want to make sure the project has attributes only, should it be p.projectList.forall(_.isInstanceOf[Attribute])?
There was a problem hiding this comment.
nit: when projects having attributes only => when the project has attributes only
There was a problem hiding this comment.
skip projections with attributes only
There was a problem hiding this comment.
Is this check necessary? I think check originalPlan.output != orderedJoins.output is enough, and faster.
There was a problem hiding this comment.
If we don't have this check, operatorOptimizationRuleSet reaches fixedPoint because ReorderJoin is re-applied in the same join trees every time the optimization rule batch invoked. This case does not happen in the master because reordered joins have Project in internal nodes (Project added by following optimization rules, e.g., ColumnPruning) and this plan structure guards this case.
There was a problem hiding this comment.
Could you add a test case which would fail to reorder joins before the fix?
@wzhfy Thanks for the review and I'll update in a few days! |
SparkQA
commented
Mar 21, 2018
Test build #88442 has finished for PR 20345 at commit
|
There was a problem hiding this comment.
The case can also happen without star schema enabled, right? Is it possible to use a simpler case like the one in pr description?
There was a problem hiding this comment.
IIUC join reorder only happens when star schema enabled now? I think this test checks the simper case?
SparkQA
commented
Mar 21, 2018
Test build #88464 has finished for PR 20345 at commit
|
SparkQA
commented
Mar 21, 2018
Test build #88465 has finished for PR 20345 at commit
|
maropu
commented
Mar 22, 2018
ping @gatorsmile@wzhfy |
SparkQA
commented
Mar 22, 2018
Test build #88503 has finished for PR 20345 at commit
|
maropu
commented
Mar 22, 2018
retest this please |
SparkQA
commented
Mar 22, 2018
Test build #88511 has finished for PR 20345 at commit
|
kindly ping |
maropu
commented
Apr 1, 2018
ping |
maropu
commented
Aug 21, 2018
retest this please |
SparkQA
commented
Aug 22, 2018
Test build #95065 has finished for PR 20345 at commit
|
maropu
commented
Aug 22, 2018
retest this please |
SparkQA
commented
Aug 22, 2018
Test build #95087 has finished for PR 20345 at commit
|
maropu
commented
Aug 22, 2018
retest this please |
SparkQA
commented
Aug 22, 2018
Test build #95104 has finished for PR 20345 at commit
|
maropu
commented
Aug 23, 2018
retest this please |
SparkQA
commented
Aug 23, 2018
Test build #95131 has finished for PR 20345 at commit
|
SparkQA
commented
Nov 21, 2019
Test build #114189 has finished for PR 20345 at commit
|
SparkQA
commented
Dec 15, 2019
Test build #115350 has finished for PR 20345 at commit
|
maropu
commented
Dec 15, 2019
retest this please |
SparkQA
commented
Dec 15, 2019
Test build #115354 has finished for PR 20345 at commit
|
SparkQA
commented
Dec 16, 2019
Test build #115369 has finished for PR 20345 at commit
|
maropu
commented
Jan 15, 2020
retest this please |
SparkQA
commented
Jan 15, 2020
Test build #116762 has finished for PR 20345 at commit
|
SparkQA
commented
Jan 21, 2020
Test build #117188 has finished for PR 20345 at commit
|
We're closing this PR because it hasn't been updated in a while. This isn't a judgement on the merit of the PR in any way. It's just a way of keeping the PR queue manageable. |
What changes were proposed in this pull request?
The current
ReorderJoinoptimizer rule cannot flatten a patternJoin -> Project -> JoinbecauseExtractFiltersAndInnerJoinsdoesn't handleProjectnodes. So, the current master cannot reorder joins in a query below;To reorder the query, this pr added code to handle
ProjectinExtractFiltersAndInnerJoins.This pr also fixed an output attribute reorder problem when joins reordered; it checks if a join reordered plan and an original plan have the same output attribute order with each other. If not,
ReorderJoinaddsProjectin the top of the join reordered plan.How was this patch tested?
This pr added new tests in
JoinOptimizationSuiteand modified some existing tests inStarJoinReorderSuiteto check ifReorderJoincan handleProjectnodes correctly. Also, it modified the existing tests inJoinReorderSuitefor the output attribute reorder issue.