emkornfield commented on code in PR #197:
URL: https://github.com/apache/parquet-format/pull/197#discussion_r1302161195
##########
src/main/thrift/parquet.thrift:
##########
@@ -974,6 +1050,13 @@ struct ColumnIndex {
/** A list containing the number of null values for each page **/
5: optional list<i64> null_counts
+ /**
+ * Repetition and definition level histograms for the pages.
+ *
+ * This contains some redundancy with null_counts, however, to accommodate
the
+ * widest range of readers both should be populated.
+ **/
+ 6: optional list<RepetitionDefinitionLevelHistogram>
repetition_definition_level_histograms;
Review Comment:
@etseidl
> My use case for the information isn't necessarily pruning (in the
filtering sense), but to figure out how large of a batch I can read from a set
of files and still remain within a memory budget.
A few clarifying questions here:
1. Does page level detail add value here? As @mapleFU stated We have this
information at the column chunk level already.
2. Is there a reason to use the index here vs having the data present on
page headers (and read as you scan)?
3. If we need to add this to OffsetIndex, it seems like we would want
SizeEstimateStatistics in full?
At least for the initial version I was trying to limit places to add new
stastistics and identify if the other cases are actual problems. As long as
others are open to it do we could add it elsewhere but I get the sense the some
of the utility might be more limited.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
