etseidl commented on code in PR #197:
URL: https://github.com/apache/parquet-format/pull/197#discussion_r1313547575
##########
src/main/thrift/parquet.thrift:
##########
@@ -191,6 +191,74 @@ enum FieldRepetitionType {
REPEATED = 2;
}
+/**
+ * A histogram of repetition and definition levels for either a page or column
+ * chunk.
+ *
+ * This is useful for:
+ * 1. Estimating the size of the data when materialized in
+ * memory
+ *
+ * 2. For filter push-down on nulls at various levels of nested
+ * structures and list lengths.
+ */
+struct RepetitionDefinitionLevelHistogram {
+ /**
+ * When present, there is expected to be one element corresponding to each
+ * repetition (i.e. size=max repetition_level+1) where each element
+ * represents the number of times the repetition level was observed in the
+ * data.
+ *
+ * This value should not be written if max_repetition_level is 0.
+ **/
+ 1: optional list<i64> repetition_level_histogram;
+ /**
+ * Same as repetition_level_histogram except for definition levels.
+ *
+ * This value should not be written if max_definition_level is 0 or 1.
Review Comment:
Now that I think about it some, I understand the first element of the
histogram for page `p` will be the same as `null_counts[p]`. The second element
of the histogram is `num_values[p] - def_hist[p][0]`, but `num_values` only
lives on the page header. It's not in the page indexes. so if you want the page
histogram without reading the page header I think you'd be out of luck. Am I
correct in my thinking? And does this argue for keeping the def histogram even
for the `max_level == 0` case? I think it will not be possible to get page size
estimates using only the indexes otherwise.
--
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]
