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 Tue, 02 Feb 2016 18:36:39 GMT

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

ASF GitHub Bot commented on DRILL-4287:

Github user jinfengni commented on a diff in the pull request:

    --- Diff: exec/java-exec/src/main/java/org/apache/drill/exec/store/dfs/FileSelection.java
    @@ -118,13 +133,34 @@ public boolean apply(@Nullable FileStatus status) {
    -    return create(nonDirectories, null, selectionRoot);
    +    final FileSelection fileSel = create(nonDirectories, null, selectionRoot);
    --- End diff --
    Agreed that it's existing create() call. It seems fine to keep it as is.  
    This new FileSelection is special, since it has excluded directories by going through
the list of file status recursively. In that sense, it's hasDirectories = false, checkedForDirectories=true,
and the list of files are already available while going through the file status list. If a
FileSelection always has to call containsDirectory() or getFile() eventually, then it might
be better to store them when they are available. But I guess it's minor thing to consider.

> 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

This message was sent by Atlassian JIRA

View raw message