wombatu-kun opened a new pull request, #8821:
URL: https://github.com/apache/paimon/pull/8821

   ### Purpose
   
   Extend the normalized-key sort fast path to `TIMESTAMP WITH LOCAL TIME 
ZONE`, a direct follow-up to #8759 which added the non-compact `TIMESTAMP` 
support. `LocalZonedTimestampType` is physically stored by the same `Timestamp` 
runtime class (millisecond + nanoOfMillisecond) and sorts by the same 
`Timestamp.compareTo`, but it was excluded from `supportNormalizedKey`, so 
sorting by such a column fell back to the per-field `RecordComparator` instead 
of the binary normalized key.
   
   The runtime writer `SortUtil.putTimestampNormalizedKey` already supports any 
precision, so the change only whitelists the extra type root in 
`SortCodeGenerator` (`supportNormalizedKey`, `getNormalizeKeyLen`, 
`prefixGetFromBinaryRow` and `getter`), reusing `DataTypeChecks.getPrecision` 
the same way `GenerateUtils` already does for the record comparator path.
   
   Micro-benchmark: sort 1,000,000 rows by a single timestamp key through 
`BinaryInMemorySortBuffer` (best of 10 iterations after 3 warmup, in-memory). 
Sorting a `TIMESTAMP` column is the control and stays flat, confirming the 
delta is the path switch and not measurement noise. `key` is the generated 
normalized-key length; `0B` means the column was excluded and the whole sort 
ran through the comparator.
   
   | case | before | after | speedup |
   | --- | --- | --- | --- |
   | `TIMESTAMP WITH LOCAL TIME ZONE(9)` non-compact | 1418 ns/row, 705 K/s 
(key=0B, fallback) | 384 ns/row, 2606 K/s (key=13B) | 3.70x |
   | `TIMESTAMP WITH LOCAL TIME ZONE(3)` compact | 1307 ns/row, 765 K/s 
(key=0B, fallback) | 367 ns/row, 2722 K/s (key=9B) | 3.56x |
   | `TIMESTAMP(9)` control | 367 ns/row | 398 ns/row | ~1x |
   | `TIMESTAMP(3)` control | 388 ns/row | 376 ns/row | ~1x |
   
   ### Tests
   
   `NormalizedKeyComputerTest` is parameterized over both timestamp roots and 
covers: key metadata (compact 9 bytes, non-compact 13 bytes, 
fully-determining), sub-millisecond ordering, `compareKey` agreeing with 
`Timestamp.compareTo` over all value pairs, and an end-to-end sort through 
`BinaryInMemorySortBuffer`. It also asserts that a `TIMESTAMP WITH LOCAL TIME 
ZONE` column and a `TIMESTAMP` column produce byte-for-byte identical 
normalized keys for the same value.
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to