drill-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jinfeng Ni (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (DRILL-3807) [Regression] Query with equality join and a FALSE condition fails to plan
Date Wed, 23 Sep 2015 17:38:04 GMT

    [ https://issues.apache.org/jira/browse/DRILL-3807?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14904879#comment-14904879
] 

Jinfeng Ni commented on DRILL-3807:
-----------------------------------

The problem seems to be caused by constant_folding rule. If I disable the constant_folding
rule, the query could get plan successfully.

{code}
alter session set `planner.enable_constant_folding` = false;

+-------+-------------------------------------------+
|  ok   |                  summary                  |
+-------+-------------------------------------------+
| true  | planner.enable_constant_folding updated.  |
+-------+-------------------------------------------+
1 row selected (0.416 seconds)
0: jdbc:drill:zk=local> explain plan for select l.l_quantity from cp.`tpch/lineitem.parquet`
l, cp.`tpch/part.parquet` p where l.l_partkey = p.p_partkey and (1 = 0);
+------+------+
| text | json |
+------+------+
| 00-00    Screen
00-01      Project(l_quantity=[$1])
00-02        HashJoin(condition=[=($0, $2)], joinType=[inner])
00-04          SelectionVectorRemover
00-05            Filter(condition=[=(1, 0)])
00-06              Scan(groupscan=[ParquetGroupScan [entries=[ReadEntryWithPath [path=classpath:/tpch/lineitem.parquet]],
selectionRoot=classpath:/tpch/lineitem.parquet, numFiles=1, columns=[`l_partkey`, `l_quantity`]]])
00-03          Scan(groupscan=[ParquetGroupScan [entries=[ReadEntryWithPath [path=classpath:/tpch/part.parquet]],
selectionRoot=classpath:/tpch/part.parquet, numFiles=1, columns=[`p_partkey`]]])

{code}

Can you see what the change that causing constant folding rule kicked in, and affect the join
query planning?




> [Regression] Query with equality join and a FALSE condition fails to plan
> -------------------------------------------------------------------------
>
>                 Key: DRILL-3807
>                 URL: https://issues.apache.org/jira/browse/DRILL-3807
>             Project: Apache Drill
>          Issue Type: Bug
>          Components: Query Planning & Optimization
>    Affects Versions: 1.2.0
>            Reporter: Aman Sinha
>            Assignee: Sean Hsuan-Yi Chu
>             Fix For: 1.2.0
>
>
> 1.2.0-SNAPSHOT behavior: 
> {code}
> 0: jdbc:drill:zk=local> explain plan for select l.l_quantity from cp.`tpch/lineitem.parquet`
l, cp.`tpch/part.parquet` p where l.l_partkey = p.p_partkey and (1 = 0);
> Error: UNSUPPORTED_OPERATION ERROR: This query cannot be planned possibly due to either
a cartesian join or an inequality join
> [Error Id: f7466d86-b709-465e-bb49-d3c51ecf941b on 172.16.0.160:31010] (state=,code=0)
> {code}
> The simplification of  ' l.l_partkey = p.p_partkey and (1 = 0)' to a False condition
is valid and accordingly Drill fails to plan due to the cartesian join introduced by the False
condition.   However,  in 1.1.0 apparently the 1=0 was converted to a LIMIT 0 which was pushed
below the Join and the query successfully planned and executed: 
> 1.1.0 behavior: 
> {code}
> 0: jdbc:drill:zk=local> explain plan for select l.l_quantity from cp.`tpch/lineitem.parquet`
l, cp.`tpch/part.parquet` p where l.l_partkey = p.p_partkey and (1 = 0);
> +------+------+
> | text | json |
> +------+------+
> | 00-00    Screen
> 00-01      Project(l_quantity=[$1])
> 00-02        HashJoin(condition=[=($0, $2)], joinType=[inner])
> 00-04          SelectionVectorRemover
> 00-05            Limit(offset=[0], fetch=[0])
> 00-06              Scan(groupscan=[ParquetGroupScan [entries=[ReadEntryWithPath [path=classpath:/tpch/lineitem.parquet]],
selectionRoot=classpath:/tpch/lineitem.parquet, numFiles=1, columns=[`l_partkey`, `l_quantity`]]])
> 00-03          Scan(groupscan=[ParquetGroupScan [entries=[ReadEntryWithPath [path=classpath:/tpch/part.parquet]],
selectionRoot=classpath:/tpch/part.parquet, numFiles=1, columns=[`p_partkey`]]])
> {code}
> [~cchang] and I looked at the commit history and it appears that the regression started
somewhere between Aug 24 and Aug 28, which is the time when we rebased on Calcite 1.4.0. 
So we need to narrow down further the change that may have caused this. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message