[
https://issues.apache.org/jira/browse/PARQUET-2261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17757694#comment-17757694
]
ASF GitHub Bot commented on PARQUET-2261:
-----------------------------------------
etseidl commented on code in PR #197:
URL: https://github.com/apache/parquet-format/pull/197#discussion_r1302246559
##########
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:
> 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.
Yes. What I'm trying to do is a log-structured merge with parquet files
sorted by a particular column. This is being done on a GPU as opposed to a set
of streaming readers, so sizing info needs to be known up front. What I do is
take page sizing info across the set of files, calculate page ranges that can
fit into GPU RAM, and then translate those page ranges to key ranges based on
the ColumnIndex. Chunk level statistics are too coarse grained for this
purpose.
>
> 2. Is there a reason to use the index here vs having the data present
on page headers (and read as you scan)?
Yes, since we're operating on a GPU, we're not streaming. Having to scan the
file to find page headers would be a non-starter. Having the info in the footer
would be a boon.
>
> 3. If we need to add this to OffsetIndex, it seems like we would want
SizeEstimateStatistics in full?
I'd have to think on this...I just need the overall sizing info. I'm not
sure how I'd use the histogram, although I'm assuming it's used to get data
sizes for fixed width data?
> 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.
Understandable. I know sticking it into the `OffsetIndex` is kind of weird.
I was originally thinking of adding a new structure like `OffsetIndex` and
placing that in the file before the other indexes, and then adding a pointer to
the info in the ColumnChunk.
Sorry for trying to piggy-back on your PR :sweat_smile: If you think this
should be a new issue I could start a discussion on the dev list.
> [Format] Add statistics that reflect decoded size to metadata
> -------------------------------------------------------------
>
> Key: PARQUET-2261
> URL: https://issues.apache.org/jira/browse/PARQUET-2261
> Project: Parquet
> Issue Type: Improvement
> Components: parquet-format
> Reporter: Micah Kornfield
> Assignee: Micah Kornfield
> Priority: Major
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
