You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@drill.apache.org by "Sean Hsuan-Yi Chu (JIRA)" <ji...@apache.org> on 2015/09/22 22:00:05 UTC
[jira] [Commented] (DRILL-3807) [Regression] Query with equality
join and a FALSE condition fails to plan
[ https://issues.apache.org/jira/browse/DRILL-3807?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14903336#comment-14903336 ]
Sean Hsuan-Yi Chu commented on DRILL-3807:
------------------------------------------
In fact, after Calcite 1.4. rebasing, ReduceExpressionsRule is improved.
The filter corresponding to the WHERE-CLAUSE, where l.l_partkey = p.p_partkey and (1 = 0), would be simplified as Filter(condition = false). (Prior to rebasing, this simplification had not been happening).
Thus, this filter would not be pushed into JOIN.
> [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
>
> 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)