drill-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF GitHub Bot (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (DRILL-4531) Query with filter and aggregate hangs in planning phase
Date Thu, 24 Mar 2016 21:03:25 GMT

    [ 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)

Mime
View raw message