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: dev-unsubscr...@parquet.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org