ColumnIndex should provide number of records skipped
- Dominant language
- Java
- Stars
- 3.1k
- Forks
- 1.6k
- Avg merge
- 3d 12h
- Merged PRs (30d)
- 33
Description
When integrating Parquet ColumnIndex, I found we need to know from Parquet that how many records that we skipped due to ColumnIndex filtering. When rowCount is 0, readNextFilteredRowGroup() just advance to next without telling the caller. See code here
In Iceberg, it reads Parquet record with an iterator. The hasNext() has the following code():
valuesRead + skippedValues < totalValues
See (
So without knowing the skipped values, it is hard to determine hasNext() or not.
Currently, we can workaround by using a flag. When readNextFilteredRowGroup() returns null, we consider it is done for the whole file. Then hasNext() just retrun false.
**Reporter**: [Xinli Shang](https://issues.apache.org/jira/secure/ViewProfile.jspa?name=shangxinli) / @shangxinli
**Assignee**: [Xinli Shang](https://issues.apache.org/jira/secure/ViewProfile.jspa?name=shangx@uber.com) / @shangxinli
**Note**: *This issue was originally created as [PARQUET-1927](https://issues.apache.org/jira/browse/PARQUET-1927). Please see the [migration documentation](https://issues.apache.org/jira/browse/PARQUET-2502) for further details.*
Contributor guide
No contributing guide indexed for this repository
Research direction
Start in parquet-hadoop/src/main/java/org/apache/parquet/hadoop/ParquetFileReader.java at readNextFilteredRowGroup(), then compare the iterator hasNext() logic in the linked Iceberg change. Trace how a row group with rowCount 0 advances and determine how the skipped record count should reach the caller; done means callers can reliably determine whether records remain after ColumnIndex filtering.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- java
- Domain
- data-engineering
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100