[
https://issues.apache.org/jira/browse/DRILL-4531?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15211964#comment-15211964
]
ASF GitHub Bot commented on DRILL-4531:
---------------------------------------
Github user jacques-n commented on the pull request:
https://github.com/apache/drill/pull/444#issuecomment-201341674
Your expectation about mixed conventions is inconsistent with my own. My
expectation: a RelSubset should only have a single convention (in fact it
should have only a single trait definition and all children should have
satisfying trait definitions). I would expect the following:
(1) Prels should only have PHYSICAL
(2) Drels should only have LOGICAL
(3) Calcite Logical Rels should only have NONE
My previous statement mistook the convention of the DrillAggregateRel in
the below. I thought it said NONE.
[rel#217:LogicalFilter.NONE.ANY([]).[],
rel#6972:DrillAggregateRel.LOGICAL.ANY([]).]
It seems like the actual problem is that LogicalFilter is allowing an input
of LOGICAL. I don't believe that LOGICAL should satisfy NONE. It seems that
LogicalFilter should assert that its child is of Convention NONE. (In other
words, a LogicalFilter shouldn't have Convention transformation properties.)
Otherwise, we'll see a large number of invalid (but infinite) plans.
> 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)
