You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues-all@impala.apache.org by "ASF subversion and git services (JIRA)" <ji...@apache.org> on 2018/11/29 22:22:00 UTC
[jira] [Commented] (IMPALA-7895) Incorrect expected results for
spillable-buffer-sizing.test
[ 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 <im...@cloudera.com>
Tested-by: Impala Public Jenkins <im...@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-unsubscribe@impala.apache.org
For additional commands, e-mail: issues-all-help@impala.apache.org