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

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

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

    https://github.com/apache/drill/pull/519#discussion_r70706252
  
    --- Diff: 
exec/java-exec/src/main/java/org/apache/drill/exec/planner/logical/partition/PruneScanRule.java
 ---
    @@ -143,6 +144,11 @@ public static final RelOptRule 
getDirFilterOnScan(OptimizerRulesContext optimize
       }
     
       protected void doOnMatch(RelOptRuleCall call, Filter filterRel, Project 
projectRel, TableScan scanRel) {
    +    if (wasAllPartitionsPruned) {
    --- End diff --
    
    Agree that this should not be an internal state.  I had added it to 
overcome an issue where the prunescan rule gets re-applied even when there are 
not qualifying partitions (this happens because we always populate the 
newPartitions list with at least 1 entry to produce a valid schema during 
execution).   
    
    I tried removing this flag but will need some associated changes to prevent 
the rule from being reapplied without termination.  The old code (without my 
patch) terminates the pruning because FileSelection.supportDirPruning() returns 
FALSE when the selection has directories.   Whereas, for this optimization I 
want to do the pruning on directories first.   So, let me think of a way to 
address that. 


> Improve metadata cache performance for queries with single partition 
> ---------------------------------------------------------------------
>
>                 Key: DRILL-4530
>                 URL: https://issues.apache.org/jira/browse/DRILL-4530
>             Project: Apache Drill
>          Issue Type: Improvement
>          Components: Query Planning & Optimization
>    Affects Versions: 1.6.0
>            Reporter: Aman Sinha
>            Assignee: Aman Sinha
>             Fix For: Future
>
>
> Consider two types of queries which are run with Parquet metadata caching: 
> {noformat}
> query 1:
> SELECT col FROM  `A/B/C`;
> query 2:
> SELECT col FROM `A` WHERE dir0 = 'B' AND dir1 = 'C';
> {noformat}
> For a certain dataset, the query1 elapsed time is 1 sec whereas query2 
> elapsed time is 9 sec even though both are accessing the same amount of data. 
>  The user expectation is that they should perform roughly the same.  The main 
> difference comes from reading the bigger metadata cache file at the root 
> level 'A' for query2 and then applying the partitioning filter.  query1 reads 
> a much smaller metadata cache file at the subdirectory level. 



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

Reply via email to