[ 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-unsubscr...@impala.apache.org For additional commands, e-mail: issues-all-h...@impala.apache.org