drill-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF GitHub Bot (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (DRILL-4287) Do lazy reading of parquet metadata cache file
Date Mon, 15 Feb 2016 02:31:18 GMT

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

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

Github user jacques-n commented on a diff in the pull request:

    https://github.com/apache/drill/pull/376#discussion_r52854886
  
    --- Diff: exec/java-exec/src/main/java/org/apache/drill/exec/planner/FileSystemPartitionDescriptor.java
---
    @@ -157,7 +159,20 @@ private String getBaseTableLocation() {
     
       @Override
       protected void createPartitionSublists() {
    -    List<String> fileLocations = ((FormatSelection) table.getSelection()).getAsFiles();
    +    Collection<String> fileLocations = null;
    +    if (scanRel instanceof DrillScanRel) {
    --- End diff --
    
    This seems like it is leaking specific implementations. Can we come up with a way to move
this around. Possibly GroupScan should have hasFiles() and getFiles()?


> Do lazy reading of parquet metadata cache file
> ----------------------------------------------
>
>                 Key: DRILL-4287
>                 URL: https://issues.apache.org/jira/browse/DRILL-4287
>             Project: Apache Drill
>          Issue Type: Bug
>          Components: Query Planning & Optimization
>    Affects Versions: 1.4.0
>            Reporter: Aman Sinha
>            Assignee: Jinfeng Ni
>
> Currently, the parquet metadata cache file is read eagerly during creation of the DrillTable
(as part of ParquetFormatMatcher.isReadable()).  This is not desirable from performance standpoint
since there are scenarios where we want to do some up-front optimizations - e.g. directory-based
partition pruning (see DRILL-2517) or potential limit 0 optimization etc. - and in such situations
it is better to do lazy reading of the metadata cache file.   
> This is a placeholder to perform such delayed reading since it is needed for the aforementioned
optimizations.  



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

Mime
View raw message