[jira] [Commented] (DRILL-3623) Limit 0 should avoid execution when querying a known schema

["ASF GitHub Bot (JIRA)" <ji...@apache.org>]

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

ASF GitHub Bot commented on DRILL-3623:
---------------------------------------

GitHub user sudheeshkatkam opened a pull request:

    https://github.com/apache/drill/pull/405

    DRILL-3623: For limit 0 queries, use a shorter path when result column types are known

    Moving from #193 to here.
    
    + There is a pull request open for first commit (DRILL-4372: #397).
    + Second commit has a "nice to have" check: ensuring planning and execution types patch.
    + My changes are in the third commit (e4cfdfa). Please review this.

You can merge this pull request into a Git repository by running:

    $ git pull https://github.com/sudheeshkatkam/drill DRILL-3623-pr

Alternatively you can review and apply these changes as the patch at:

    https://github.com/apache/drill/pull/405.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

    This closes #405
    
----
commit c553365e39947ba6c95d645cc971cf4d696ee758
Author: Sudheesh Katkam <sk...@maprtech.com>
Date:   2015-12-22T04:38:59Z

    DRILL-4372: Expose the functions return type to Drill
    
    - Drill-Calite version update:
    This commit needs to have Calcite's patch (CALCITE-1062) to plugin customized SqlOperator.
    
    - FunctionTemplate
    Add FunctionArgumentNumber annotation. This annotation element tells if the number of argument(s) is fixed or arbitrary (e.g., String concatenation function).
    
    Due to this modification, there are some minor changes in DrillFuncHolder, DrillFunctionRegistry and FunctionAttributes.
    
    - Checker
    Add a new Checker (which Calcite uses to validate the legitimacy of the number of argument(s) for a function) to allow functions with arbitrary arguments to pass Caclite's validation
    
    - Type conversion between Drill and Calcite
    DrillConstExector is given a static method getDrillTypeFromCalcite() to convert Calcite types to Drill's.
    
    - Extract function's return type inference
    Unlike other functions, Extract function's return type can be determined solely based on the first argument. A logic is added in to allow this inference to happen
    
    - DrillCalcite wrapper:
    From the aspects of return type inference and argument type checks, Calcite's mechanism is very different from Drill's. In addition, currently, there is no straightforward way for Drill to plug-in customized mechanisms to Calcite. Thus, wrappers are provided to serve the objective.
    
    Except for the mechanisms of type inference and argument type checks, these wrappers just forward any method calls to the wrapped SqlOpertor, SqlFuncion or SqlAggFunction to respond.
    
    A interface DrillCalciteSqlWrapper is also added for the callers of the three wrappers to get the wrapped objects easier.
    
    Due to these wrappers, UnsupportedOperatorsVisitor is modified in a minor manner.
    
    - Calcite's SqlOpertor, SqlFuncion or SqlAggFunction are wrapped in DrillOperatorTable
    Instead of returning Caclite's native SqlOpertor, SqlFuncion or SqlAggFunction, return the wrapped ones to ensure customized behaviors can be adopted.
    
    - Type inference mechanism
    This mechanism is used across all SqlOpertor, SqlFuncion or SqlAggFunction. Thus, it is factored out as its own method in TypeInferenceUtils
    
    - Upgrade Drill-Calcite
    
    Bump version number to 1.4.0-drill-test-r16
    
    - Implement two argument version of lpad, rpad
    
    - Implement one argument version of ltrim, rtrim, btrim

commit c3f0649e3ebb45d54e747f099d6699150bfa9869
Author: Hsuan-Yi Chu <hs...@usc.edu>
Date:   2016-02-03T05:17:50Z

    DRILL-4372: Part 2: Optionally ensure planning and execution types match

commit e4cfdfa9b0562d52ac07f6d80860a82fa8baba40
Author: Sudheesh Katkam <sk...@maprtech.com>
Date:   2016-03-03T21:25:39Z

    DRILL-3623: For limit 0 queries, use a shorter path when result column types are known

----


> Limit 0 should avoid execution when querying a known schema
> -----------------------------------------------------------
>
>                 Key: DRILL-3623
>                 URL: https://issues.apache.org/jira/browse/DRILL-3623
>             Project: Apache Drill
>          Issue Type: Sub-task
>          Components: Storage - Hive
>    Affects Versions: 1.1.0
>         Environment: MapR cluster
>            Reporter: Andries Engelbrecht
>            Assignee: Sudheesh Katkam
>              Labels: doc-impacting
>             Fix For: Future
>
>
> Running a select * from hive.table limit 0 does not return (hangs).
> Select * from hive.table limit 1 works fine
> Hive table is about 6GB with 330 files with parquet using snappy compression.
> Data types are int, bigint, string and double.
> Querying directory with parquet files through the DFS plugin works fine
> select * from dfs.root.`/user/hive/warehouse/database/table` limit 0;



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