[GH-3609]: Add new sort order for int96 timestamps#3610
Conversation
|
Please resolve the conflicts. |
@wgtmac Sorry for the delay, I was on holiday last week. Conflicts are resolved now |
| * | ||
| * Two-level comparison, matching the INT96 timestamp sort order: | ||
| * 1. Compare the last 4 bytes (Julian day) as a signed little-endian int32. | ||
| * 2. If equal, compare the first 8 bytes (nanos) as a signed little-endian int64. |
There was a problem hiding this comment.
The correctness of this depends on the two fields so I think we have to be more careful since the caller may pass in something unexpected.
I think that we need to validate that the nanosecond value is positive and less than the number of nanoseconds per day. If either of these is violated, then this sort order is no longer correct.
There was a problem hiding this comment.
Added validation for both cases
| * min/max statistics in place. This simulates a legacy writer that emitted INT96 stats under | ||
| * TYPE_ORDER before INT96_TIMESTAMP_ORDER existed; such stats must be ignored by the reader. | ||
| */ | ||
| private static void downgradeInt96ToTypeOrder(FileMetaData footer) { |
There was a problem hiding this comment.
Can you add a couple more cases? I'd like to see UNDEFINED, TYPE_DEFINED_ORDER, and unset cases.
There was a problem hiding this comment.
Removed this helper and added both testReaderIgnoresInt96StatsWithTypeDefinedOrder and testReaderIgnoresInt96StatsWhenColumnOrdersAbsent
There was a problem hiding this comment.
I wasn't able to test UNDEFINED as I didn't find a good way to serialize an undefined value for the union
|
I think there are a few things to be fixed, but overall I trust that this works. |
Rationale for this change
See parquet-format proposal for rationale: apache/parquet-format#584
What changes are included in this PR?
Add new
INT96_TIMESTAMP_ORDERsort order and related parsing.Are these changes tested?
Yes, new unit tests.
Are there any user-facing changes?
Two new flags and a Thrift change.
Closes #3609