You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@spark.apache.org by "Apache Spark (Jira)" <ji...@apache.org> on 2020/09/03 16:10:00 UTC
[jira] [Assigned] (SPARK-32687) CostBasedJoinReorder should have
deterministic Optimization result
[ https://issues.apache.org/jira/browse/SPARK-32687?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Apache Spark reassigned SPARK-32687:
------------------------------------
Assignee: Apache Spark
> CostBasedJoinReorder should have deterministic Optimization result
> ------------------------------------------------------------------
>
> Key: SPARK-32687
> URL: https://issues.apache.org/jira/browse/SPARK-32687
> Project: Spark
> Issue Type: Improvement
> Components: SQL
> Affects Versions: 3.0.0, 3.0.1, 3.1.0
> Reporter: Yang Jie
> Assignee: Apache Spark
> Priority: Minor
>
> In [SPARK-32526|https://github.com/apache/spark/pull/29434], we found the optimization result of CostBasedJoinReorder is non-deterministic now, it affected by the input order if there more than one same cost candidate plans.
> The test case named "Test 4: Star with several branches" in StarJoinCostBasedReorderSuite is a typical case.
> If we use {{permutations of 10 tables(}}{{d1, t3, t4, f1, d2, t5, t6, d3, t1, t2}}{{) as input set, there will be total of 3628000 candidate input plan with different orders.}}
>
> We define original expected optimization result as *A:*
>
> {code:java}
> f1.join(d3, Inner, Some(nameToAttr("f1_fk3") === nameToAttr("d3_pk")))
> .join(d1, Inner, Some(nameToAttr("f1_fk1") === nameToAttr("d1_pk")))
> .join(d2, Inner, Some(nameToAttr("f1_fk2") === nameToAttr("d2_pk")))
> .join(t4.join(t3, Inner, Some(nameToAttr("t3_c2") === nameToAttr("t4_c2"))), Inner,
> Some(nameToAttr("d1_c2") === nameToAttr("t3_c1")))
> .join(t2.join(t1, Inner, Some(nameToAttr("t1_c2") === nameToAttr("t2_c2"))), Inner,
> Some(nameToAttr("d3_c2") === nameToAttr("t1_c1")))
> .join(t5.join(t6, Inner, Some(nameToAttr("t5_c2") === nameToAttr("t6_c2"))), Inner,
> Some(nameToAttr("d2_c2") === nameToAttr("t5_c1")))
> {code}
>
> {{and define the other one optimization result as }}{{*B*}}
> {code:java}
> f1.join(d3, Inner, Some(nameToAttr("f1_fk3") === nameToAttr("d3_pk")))
> .join(d2, Inner, Some(nameToAttr("f1_fk2") === nameToAttr("d2_pk")))
> .join(d1, Inner, Some(nameToAttr("f1_fk1") === nameToAttr("d1_pk")))
> .join(t4.join(t3, Inner, Some(nameToAttr("t3_c2") === nameToAttr("t4_c2"))), Inner,
> Some(nameToAttr("d1_c2") === nameToAttr("t3_c1")))
> .join(t2.join(t1, Inner, Some(nameToAttr("t1_c2") === nameToAttr("t2_c2"))), Inner,
> Some(nameToAttr("d3_c2") === nameToAttr("t1_c1")))
> .join(t5.join(t6, Inner, Some(nameToAttr("t5_c2") === nameToAttr("t6_c2"))), Inner,
> Some(nameToAttr("d2_c2") === nameToAttr("t5_c1")))
> {code}
>
> {{Then we use "Test 4: Star with several branches" in StarJoinCostBasedReorderSuite to test optimization results of 3628000 inputs as described above. We found that 1813600 results were candidate *A* and 1814400 results were candidate *B* because f1.join(d3).join(d1).join(d2) has the same cost with }}{{f1.join(d3).join(d2).join(d1), both Cost(200, 9200), and the candidate plan generated first will be choice.}}
> Now the result of CostBasedJoinReorder rule is non-deterministic, we need to find a way to make it deterministic even if the input order is different.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@spark.apache.org
For additional commands, e-mail: issues-help@spark.apache.org