[ https://issues.apache.org/jira/browse/IMPALA-7895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16703899#comment-16703899 ]
ASF subversion and git services commented on IMPALA-7895: --------------------------------------------------------- Commit e64261adb780518b5fd03e2702c9b2912a9cd174 in impala's branch refs/heads/master from [~paul-rogers] [ https://git-wip-us.apache.org/repos/asf?p=impala.git;h=e64261a ] IMPALA-7895: Incorrect expected results for spillable-buffer-sizing.test Expected results from spillable-bufe-sizing.test and max-row-size.test included incorrect expressions: the un-anayzed GROUP BY expression with ordinals represented as (invalid) casts. SelectStmt is a bit of a mess. There are two copies of the grouping expressions. Here we want to use the analyzed version with the ordinals replaced. Testing: * Problem found when running PlannerTest. PlannerTest now passes, with correct results, after this change. * Turns out there is another path used when generating SQL for a view which does toSql() on an unanalyzed query. Added unit tests for this case. Change-Id: I413bded920e27fe9f41f0ea989696a0c8f92fe4a Reviewed-on: http://gerrit.cloudera.org:8080/11993 Reviewed-by: Impala Public Jenkins <impala-public-jenk...@cloudera.com> Tested-by: Impala Public Jenkins <impala-public-jenk...@cloudera.com> > Incorrect expected results for spillable-buffer-sizing.test > ----------------------------------------------------------- > > Key: IMPALA-7895 > URL: https://issues.apache.org/jira/browse/IMPALA-7895 > Project: IMPALA > Issue Type: Bug > Components: Frontend > Affects Versions: Impala 3.0 > Reporter: Paul Rogers > Assignee: Paul Rogers > Priority: Minor > > A recent change appears to have caused a test to expect the wrong rewritten > SQL in {{spillable-buffer-sizing.test}}. > {noformat} > # Mid NDV aggregation - should scale down buffers to intermediate size. > select straight_join l_orderkey, o_orderstatus, count(*) > from tpch_parquet.lineitem > join tpch_parquet.orders on o_orderkey = l_orderkey > group by 1, 2 > having count(*) = 1 > ---- DISTRIBUTEDPLAN > Max Per-Host Resource Reservation: Memory=82.00MB Threads=7 > Per-Host Resource Estimates: Memory=244MB > Analyzed query: SELECT > -- +straight_join > l_orderkey, o_orderstatus, count(*) FROM tpch_parquet.lineitem INNER JOIN > tpch_parquet.orders ON o_orderkey = l_orderkey GROUP BY CAST(1 AS > INVALID_TYPE), > CAST(2 AS INVALID_TYPE) HAVING count(*) = CAST(1 AS BIGINT) > {noformat} > Correct rewritten SQL: > {noformat} > Analyzed query: SELECT > -- +straight_join > l_orderkey, o_orderstatus, count(*) FROM tpch_parquet.lineitem INNER JOIN > tpch_parquet.orders ON o_orderkey = l_orderkey GROUP BY l_orderkey, > o_orderstatus HAVING count(*) = CAST(1 AS BIGINT) > {noformat} > The same problem occurs in {{max-rows-test.test}}. > The problem is due to the existence of two copies of the grouping > expressions. The {{toSql()}} function used the original, unanalyzed copy, not > the rewritten copy with ordinal replacements. -- 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