[ https://issues.apache.org/jira/browse/IMPALA-8263?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Tim Armstrong resolved IMPALA-8263. ----------------------------------- Resolution: Not A Bug The row size of the left size is larger so this is actually correct (Impala mostly makes these decisions based on byte size rather than row count). > Planner failed to flip build/probe side of join > ----------------------------------------------- > > Key: IMPALA-8263 > URL: https://issues.apache.org/jira/browse/IMPALA-8263 > Project: IMPALA > Issue Type: Bug > Components: Frontend > Affects Versions: Impala 3.1.0 > Reporter: Paul Rogers > Priority: Major > > TPC-H query 8 was reviewed after applying the changes proposed for > DRILL-8014. (See {{tpch-all.test}}.) The revised plan has better cardinality > number, but contains this odd structure: > {noformat} > 11:HASH JOIN [INNER JOIN] > | hash predicates: o_custkey = c_custkey > | row-size=139B cardinality=39.66K > | > |--04:SCAN HDFS [tpch.customer] > | row-size=10B cardinality=150.00K > | > 10:HASH JOIN [INNER JOIN] > | hash predicates: o_orderkey = l_orderkey > | row-size=129B cardinality=39.66K > {noformat} > As I understand it, the planner should flip the left and right sides of an > inner join if the right side (the 04 scan) has a larger cardinality than the > left (join 10) side. That flip did not happen in this case, causing the join > to build a hash table about 4 times larger than necessary. > Perhaps there is some other constraint. Investigate to determine if the > behavior is correct (and if so why), or the source of incorrect behavior. -- This message was sent by Atlassian Jira (v8.3.4#803005) --------------------------------------------------------------------- To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org For additional commands, e-mail: issues-all-h...@impala.apache.org