-
Notifications
You must be signed in to change notification settings - Fork 1.3k
[parquet] Use MICROS annotation for TIMESTAMP(n<=3) columns (Iceberg v2 compatibility) #8230
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Changes from all commits
25c0f5c
7142932
f9315e0
fb82382
5bc2d62
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -223,8 +223,8 @@ private SimpleColStats toTimestampStats(Statistics<?> stats, int precision) { | |
| if (precision <= 3) { | ||
| LongStatistics longStats = (LongStatistics) stats; | ||
| return new SimpleColStats( | ||
| Timestamp.fromEpochMillis(longStats.getMin()), | ||
| Timestamp.fromEpochMillis(longStats.getMax()), | ||
| Timestamp.fromMicros(longStats.getMin()), | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This makes footer stats decoding depend only on the Paimon field precision, but existing files written before this change still use TIMESTAMP_MILLIS and store min/max in epoch milliseconds. The PR description says those files remain readable; however any stats extraction path (for example migrate/clone or metadata regeneration) would now decode an old value like 1704067200123 as epoch micros and produce a 1970-era bound. Can we inspect the Parquet logical unit from stats.type().getLogicalTypeAnnotation() / column metadata, like the reader does, and keep MILLIS for legacy files? |
||
| Timestamp.fromMicros(longStats.getMax()), | ||
| stats.getNumNulls()); | ||
| } else if (precision <= 6) { | ||
| LongStatistics longStats = (LongStatistics) stats; | ||
|
|
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -299,11 +299,7 @@ private static Comparable<?> toParquetObject( | |
| } else if (value instanceof Timestamp) { | ||
| Timestamp timestamp = (Timestamp) value; | ||
| int precision = getTimestampPrecision(type); | ||
| if (precision <= 3) { | ||
| // milliseconds | ||
| return timestamp.getMillisecond(); | ||
| } else if (precision <= 6) { | ||
| // microseconds | ||
| if (precision <= 6) { | ||
| return timestamp.toMicros(); | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. [P1] This makes Parquet predicate pushdown use epoch micros for every
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This filter literal is now always epoch micros for TIMESTAMP(0..6), but old Paimon files with precision 0..3 still store epoch milliseconds. The filter is built in ParquetFileFormat from the table type before ParquetReaderFactory opens each file, so it cannot distinguish TIMESTAMP_MILLIS files from new TIMESTAMP_MICROS files. For an old file, ts = 2024-01-01 becomes 1704067200000000 while the row-group stats/data are around 1704067200000, so Parquet can incorrectly prune matching row groups. We need to build the timestamp predicate after seeing the file schema, or otherwise avoid this pushdown for legacy low-precision timestamp files. |
||
| } | ||
| // precision > 6 uses INT96, not supported | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
[P2] The stats extractor also needs to decode based on the Parquet file annotation, not only the Paimon field precision. Old Paimon files with
TIMESTAMP(0..3)haveTIMESTAMP_MILLISfooter stats, so reading them withfromMicrosturns their min/max into values about 1000x too small. This affects any path that re-extracts stats from existing Parquet files, such as migration/metadata rebuild workflows. Sincestats.type()carries the primitive logical annotation, can we branch on itsTimeUnithere the same way the vector reader does?