[
https://issues.apache.org/jira/browse/DRILL-4531?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15211457#comment-15211457
]
ASF GitHub Bot commented on DRILL-4531:
---------------------------------------
Github user jinfengni commented on the pull request:
https://github.com/apache/drill/pull/444#issuecomment-201151771
Adding assertion to DrillAggregateRel did not show new failure when using
the default FilterAggregateTransposeRule. In the rule, copy() method is used to
create new instance of aggregate. So, the aggregate created by this rule should
not violate the convention check.
The patten of mixed rels does happen and it's the expected thing, since
Drill's logical planning is dealing with two convention: NONE and LOGICAL. So,
at any time, the RelSet would have RelSubSets for both conventions. It's normal
to see a LogicalFilter whose input is a RelSubset with a DrillAggregate as a
member.
The problem is not we should not have such mixed patten. In stead, the
problem is that the Rule should not match such pattern. If the rule matches
such mixed Rel, then looks like it could cause problem. With the default rule,
the trace of running 50 seconds shows FilterAggregateTransposeRule is fired
abnormally high (it could be even high if it does not timeout)
1055 [FilterAggregateTransposeRule]
45 [DrillPushProjectPastFilterRule]
38 [ProjectMergeRule:force_mode]
32 [DrillReduceExpressionsRule(Filter)]
30 [ReduceExpressionsRule_Project]
30 [DrillProjectRule]
26 [DrillAggregateRule]
If we add the restriction, then the new rule was just fired coupled of
times.
> Query with filter and aggregate hangs in planning phase
> -------------------------------------------------------
>
> Key: DRILL-4531
> URL: https://issues.apache.org/jira/browse/DRILL-4531
> Project: Apache Drill
> Issue Type: Bug
> Components: Query Planning & Optimization
> Reporter: Jinfeng Ni
> Assignee: Jinfeng Ni
> Fix For: 1.7.0
>
>
> For the following query,
> {code}
> SELECT cust.custAddress,
> lineitem.provider
> FROM (
> SELECT cast(c_custkey AS bigint) AS custkey,
> c_address AS custAddress
> FROM cp.`tpch/customer.parquet` ) cust
> LEFT JOIN
> (
> SELECT DISTINCT l_linenumber,
> CASE
> WHEN l_partkey IN (1, 2) THEN 'Store1'
> WHEN l_partkey IN (5, 6) THEN 'Store2'
> END AS provider
> FROM cp.`tpch/lineitem.parquet`
> WHERE ( l_orderkey >=20160101 AND l_partkey <=20160301)
> AND l_partkey IN (1,2, 5, 6) ) lineitem
> ON cust.custkey = lineitem.l_linenumber
> WHERE provider IS NOT NULL
> GROUP BY cust.custAddress,
> lineitem.provider
> ORDER BY cust.custAddress,
> lineitem.provider;
> {code}
> When run on today's master branch commit:
> 79a3c164c1df7a5d7a0b82574316b4a0b1c7593e, query just hangs there in the
> planning phase.
> Log shows that it stuck in Drill_Logical planning phase.
>
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
