[
https://issues.apache.org/jira/browse/DRILL-1946?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14290935#comment-14290935
]
Aman Sinha commented on DRILL-1946:
-----------------------------------
The fix for DRILL-2063 (ensure uniqueness of fields in output row type of an
AggregateRel) also fixes the wrong result for this issue. Lowering the
slice_target forces multiphase aggregate which also affects the field
references from the 2nd phase aggregate to its child operators, so it seems
reasonable that the root cause of both issues is the same.
> Wrong result for aggregation query with lower slice_target
> ----------------------------------------------------------
>
> Key: DRILL-1946
> URL: https://issues.apache.org/jira/browse/DRILL-1946
> Project: Apache Drill
> Issue Type: Bug
> Components: Query Planning & Optimization
> Affects Versions: 0.7.0
> Reporter: Aman Sinha
> Assignee: Aman Sinha
> Fix For: 0.8.0
>
>
> Here's the result with the default value of slice_target for the following
> query:
> {code}
> select count(*) from (
> SELECT l_suppkey, sum(l_extendedprice)/sum(l_quantity)
> FROM cp.`tpch/lineitem.parquet`
> WHERE (l_orderkey in (SELECT o_orderkey FROM cp.`tpch/orders.parquet`
> WHERE o_custkey < 2) )
> GROUP BY l_suppkey
> );
> +------------+
> | EXPR$0 |
> +------------+
> | 29 |
> +------------+
> {code}
> I lowered the slice_target in order to force exchanges in the following
> query. The result is wrong.
> {code}
> 0: jdbc:drill:zk=local> alter session set `planner.slice_target` = 1;
> select count(*) from (
> SELECT l_suppkey, sum(l_extendedprice)/sum(l_quantity)
> FROM cp.`tpch/lineitem.parquet`
> WHERE (l_orderkey in (SELECT o_orderkey FROM cp.`tpch/orders.parquet`
> WHERE o_custkey < 2) )
> GROUP BY l_suppkey
> );
> +------------+
> | EXPR$0 |
> +------------+
> | 14 |
> +------------+
> {code}
> The Explain plan for the second query has multiphase aggregates. When I set
> planner.enable_multiphase_agg = false, the result is correct, so it seems to
> be a multiphase aggregate issue based on a preliminary analysis (although
> there might be other things going on).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)