You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@drill.apache.org by "Aman Sinha (JIRA)" <ji...@apache.org> on 2015/04/17 16:22:59 UTC

[jira] [Commented] (DRILL-2732) Different logical plan based on field names

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

Aman Sinha commented on DRILL-2732:
-----------------------------------

This could be JSON specific.  Are you seeing similar behavior with Parquet ?  Try looking at why the DrillPushProjIntoScan  rule is not pushing the projected columns into the scan.  The JSONFormatPlugin does support projection push down.  I did a  'explain plan including all attributes for <your query>' to see what is the cumulative cost of the two plans - with and without the Project.  And they both were the same.  This indicates that pushing the projection into the scan did not change the cost for some reason, so the optimizer retained the previous plan.  I haven't looked in more detail (can do it after 0.9 is released)  but if you want to dig further fee free to assign the JIRA to yourself.

> Different logical plan based on field names
> -------------------------------------------
>
>                 Key: DRILL-2732
>                 URL: https://issues.apache.org/jira/browse/DRILL-2732
>             Project: Apache Drill
>          Issue Type: Bug
>          Components: Query Planning & Optimization
>    Affects Versions: 0.8.0
>            Reporter: Adam Gilmore
>            Assignee: Jinfeng Ni
>
> The following two queries produce different logical plans:
> {code}
> select count(*) from cp.`employee.json` where mytestFieldNum = 4 and myOtherLongIdString = '12345'
> {code}
> {code}
> select count(*) from cp.`employee.json` where my_testFieldNum = 4 and my_OtherLongIdString = '12345'
> {code}
> The latter adds a project step to the logical plan.  The ramifications of this means that, for example, the Mongo storage provider will not push down filters because it's matching on a scan/filter.
> It has nothing to do with the underscore - in fact, it seems if you substitute the underscore with a variety of characters, it produces different results.
> It also seems to not be reliant on the length of the field names in question.
> These two queries should really produce identical logical plans.



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