[
https://issues.apache.org/jira/browse/DRILL-4287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15149358#comment-15149358
]
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_r53083386
--- Diff:
exec/java-exec/src/main/java/org/apache/drill/exec/store/dfs/FileSelection.java
---
@@ -47,6 +49,14 @@
public List<String> files;
public final String selectionRoot;
+ private enum StatusType {
+ CHECKED_DIRS, // whether we have already checked for directories
+ HAS_DIRS, // whether directories were found in the selection
+ EXPANDED_DIRS // whether this selection has been expanded to
files
+ }
+
+ private final BitSet dirStatus;
--- End diff --
You took this differently than I meant it. My proposal was that
FileSelection has various states:
NOT_CHECKED_DIRS => (HAS_DIRS | NO_DIRS) => EXPANDED
Doesn this lifecycle describe the state of FileSelection? This way you
don't have the multi-state-management problem you currently have below with
this kind of construct:
fileSel.setExpanded(true);
fileSel.setCheckedForDirectories(true);
fileSel.setHasDirectories(false); // already expanded
For each of the enumerations, we can return the right booleans that you
need through enumerator constructors.
> 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)
