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

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

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

    https://github.com/apache/drill/pull/345#discussion_r52516038
  
    --- Diff: 
exec/java-exec/src/main/java/org/apache/drill/exec/store/parquet/ParquetGroupScan.java
 ---
    @@ -182,10 +183,24 @@ public ParquetGroupScan( //
         }
     
         this.selectionRoot = selectionRoot;
    -    if (selection instanceof ParquetFileSelection) {
    -      final ParquetFileSelection pfs = 
ParquetFileSelection.class.cast(selection);
    -      this.parquetTableMetadata = pfs.getParquetMetadata();
    +
    +    FileSelection newSelection = null;
    +    if (!selection.isExpanded()) {
    +      FileStatus firstPath = selection.getFirstPath(fs);
    +      Path p = new Path(firstPath.getPath(), Metadata.METADATA_FILENAME);
    +      if (!fs.exists(p)) { // no metadata cache
    +        if (selection.checkedForDirectories() && 
selection.hasDirectories()) {
    --- End diff --
    
    This won't work if `checkedForDirectories==false`, right ?
    `hasDirectories()` already uses `checkedForDirectories` internally, the 
following should work:
     
        if (selection.hasDirectories()) {


> 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)

Reply via email to