drill-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From paul-rogers <...@git.apache.org>
Subject [GitHub] drill pull request #611: Drill-4800: Improve parquet reader performance
Date Fri, 04 Nov 2016 17:13:07 GMT
Github user paul-rogers commented on a diff in the pull request:

    https://github.com/apache/drill/pull/611#discussion_r86591181
  
    --- Diff: exec/java-exec/src/test/java/org/apache/drill/exec/physical/impl/writer/TestParquetWriter.java
---
    @@ -859,5 +865,40 @@ public void testLastPageOneNull() throws Exception {
             "cp.`parquet/last_page_one_null.parquet`");
       }
     
    +  @Test
    --- End diff --
    
    Should there be tests for other code paths introduced in this commit?
    
    * Failures in the parallel tasks (see comments above about handling such failures.)
    * Verifying that the various "determine size parallel" code paths are exercised?
    * Verify that pages were, indeed, read in parallel?
    * What happens if more parallel readers are needed than threads available in the pool?
    * What happens with parallelization if the file has 1000 columns (which, presumably, could
cause 1K parallel reads?) Some upper limit on parallelization?
    * Verify the five decompression paths?
    
    Might the above code need a bit of instrumentation so the test can validate that the parallel
reader was, in fact, used and exercised the interesting code paths?


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---

Mime
View raw message