[
https://issues.apache.org/jira/browse/DRILL-4531?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15210944#comment-15210944
]
ASF GitHub Bot commented on DRILL-4531:
---------------------------------------
Github user jinfengni commented on a diff in the pull request:
https://github.com/apache/drill/pull/444#discussion_r57387288
--- Diff:
exec/java-exec/src/main/java/org/apache/drill/exec/planner/logical/DrillFilterAggregateTransposeRule.java
---
@@ -0,0 +1,28 @@
+/**
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+package org.apache.drill.exec.planner.logical;
+
+import org.apache.calcite.rel.rules.FilterAggregateTransposeRule;
+
+public class DrillFilterAggregateTransposeRule{
--- End diff --
The customized rule is not only adding a customer filter factory, it also
specifies the filter / aggregate has to be in Drill Logical. The default rule
patten will match Filter and Aggregate [1]. In debug, we saw that the default
one will match with a LogicalFilter on top of DrillAggregate, which I feel is
not right. We do not want to max a Rels with mixed conventions.
@sudheeshkatkam helped track to the following error, which seems indicate
the rule matching a LogicalFilter /DrillAggregate. Then, exception handling
seems hit a cyclic somehow, and hang there forever.
The intention of this customized rule is to ensure that we do not match rel
nodes with mixed convention.
Internal error: Error while applying rule FilterAggregateTransposeRule,
args
[rel#217:LogicalFilter.NONE.ANY([]).[[]](input=rel#126:Subset#5.LOGICAL.ANY([]).[],condition=IS
NOT NULL($1)),
rel#6972:DrillAggregateRel.LOGICAL.ANY([]).[](input=rel#6971:Subset#1714.NONE.ANY([]).[],group={0,
1})]
[1]
https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/rel/rules/FilterAggregateTransposeRule.java#L52-L53
> 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)
