[jira] [Commented] (IMPALA-8002) Unstable join ordering for equivalent tables

["Paul Rogers (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/IMPALA-8002?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16783891#comment-16783891 ] 

Paul Rogers commented on IMPALA-8002:
-------------------------------------

See IMPALA-8219 for one way to resolve this issue.

> Unstable join ordering for equivalent tables
> --------------------------------------------
>
>                 Key: IMPALA-8002
>                 URL: https://issues.apache.org/jira/browse/IMPALA-8002
>             Project: IMPALA
>          Issue Type: Bug
>          Components: Frontend
>    Affects Versions: Impala 3.1.0
>            Reporter: Paul Rogers
>            Priority: Minor
>
> Consider the following test: {{PlannerTest.testJoins()}}:
> {noformat}
> select t1.d, t2.d
> from functional.nulltable t1, functional.nulltable t2, functional.nulltable t3
> where t1.d IS DISTINCT FROM t2.d
> and t3.a != t2.g
> ---- PLAN
> PLAN-ROOT SINK
> |
> 04:NESTED LOOP JOIN [INNER JOIN]
> |  predicates: t3.a != t2.g
> |
> |--02:SCAN HDFS [functional.nulltable t3]
> |     partitions=1/1 files=1 size=18B
> |
> 03:NESTED LOOP JOIN [INNER JOIN]
> |  predicates: t1.d IS DISTINCT FROM t2.d
> |
> |--00:SCAN HDFS [functional.nulltable t1]
> |     partitions=1/1 files=1 size=18B
> |
> 01:SCAN HDFS [functional.nulltable t2]
>    partitions=1/1 files=1 size=18B
> {noformat}
> Despite no changes in the planner code, on one run the order flipped to the above. Previously, 01 was t1 and 00 was t2.
> Likely, the behavior when two tables are equivalent has some kind of non-determinism, perhaps storing candidates in a Java Set or Map with undefined order.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

---------------------------------------------------------------------
To unsubscribe, e-mail: issues-all-unsubscribe@impala.apache.org
For additional commands, e-mail: issues-all-help@impala.apache.org