Regarding the choice of 12-byte ints rather than 16-byte: this is purely
a storage footprint optimization, right? Or do some readers also plan to
read these as 12-byte ints in memory?
If it's purely a footprint optimization, I'll point that 16-byte ints
with 0s in the top 4 bytes should compress pretty well, especially using
BYTE_STREAM_SPLIT.
By the way, DECIMAL can already annotate a FLBA<N> with an open-ended N.
Perhaps that should be the solution here too, rather than mandating a
particular byte width?
Regards
Antoine.
Le 10/07/2026 à 07:28, Micah Kornfield a écrit :
Hi Divjot,
I reviewed the doc and it seems like a pragmatic solution to a long
standing gap in parquet.
Let's maybe what until next week to collect feedback and if there are no
objections we can hopefully start on POCs.
Cheers,
Micah
On Wednesday, July 8, 2026, Divjot Arora via dev <[email protected]>
wrote:
Hi folks,
We're interested in supporting the full SQL timestamp range (year 0001 to
9999) in nanosecond precision. Parquet currently cannot do this via INT64 +
the TimestampType logical type, so I'm sharing a proposal to allow the
TimestampType annotation on FIXED_LEN_BYTE_ARRAY of size 12 (96-bits):
https://docs.google.com/document/d/1H43RQZhWKcg9c4tJO5W87YxhbUxN7
qGSFxJBrrwWOfY/edit?tab=t.0.
Please take a look if interested and feel free to leave comments on the
document.
Best,
Divjot Arora
