You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@drill.apache.org by "Sorabh Hamirwasia (JIRA)" <ji...@apache.org> on 2018/08/04 02:58:00 UTC

[jira] [Updated] (DRILL-6665) MergingReceiverBatch produces OK_NEW_SCHEMA post build schema phase

     [ https://issues.apache.org/jira/browse/DRILL-6665?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Sorabh Hamirwasia updated DRILL-6665:
-------------------------------------
    Attachment: Plan.pdf

> MergingReceiverBatch produces OK_NEW_SCHEMA post build schema phase
> -------------------------------------------------------------------
>
>                 Key: DRILL-6665
>                 URL: https://issues.apache.org/jira/browse/DRILL-6665
>             Project: Apache Drill
>          Issue Type: Bug
>          Components: Execution - Relational Operators
>    Affects Versions: 1.14.0
>            Reporter: Sorabh Hamirwasia
>            Assignee: Sorabh Hamirwasia
>            Priority: Major
>         Attachments: Plan.pdf
>
>
> MergingRecordBatch produces OK_NEW_SCHEMA as part of first output batch post buildSchema phase. This is not necessary since in BuildSchema phase it already has the batch with schema and it always produces container of type SV NONE as well. Because of this behavior query like below doesn't work since there is HashAgg downstream to MergingReceiver which doesn't handle OK_NEW_SCHEMA post buildSchema phase.
>  
> {code:java}
> SELECT cust.c_custkey, cust.c_name, sum(cust.c_acctbal) 
> FROM (SELECT customer.c_custkey, customer.c_name, customer.c_acctbal
> FROM dfs.singleJson.`customer.json` customer 
> ORDER BY customer.c_name) cust
> GROUP BY cust.c_custkey, cust.c_name{code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)