PLAIN and uncompressed is common for low latency/high performance.
Decompression is expensive.
I haven't given too much thought on FLBA<N>. It should work but I do not
see what we get out of it.
> I'm not sure what your expectations are wrt. "slow" vs. "fast".
My expectation is that anything involving general compression is going to
be trash compared to DBP - BYTE_STREAM_SPLIT or not.
I implemented and ran bss+lz4 and confirmed it.
int96 nanos, Xeon 6975P DBP 64+32 bss_zstd bss_lz4
Size (bytes/value, lower better)
sorted 1us 1.64 2.03 2.13
sorted 1ms 2.89 3.09 3.38
sorted 1s 4.14 4.28 4.57
1ms, ms-quant 2.88 1.89 2.70
1s, s-quant 4.13 2.27 3.08
batched 1k/s 0.92 0.013 0.064
unsorted 1h 5.39 5.37 5.64
Encode (M ts/s, higher better)
sorted 1us 305 78 92
sorted 1ms 286 70 87
sorted 1s 285 63 80
1ms, ms-quant 304 32 59
1s, s-quant 251 26 53
batched 1k/s 321 78 95
unsorted 1h 278 56 82
Decode (ns/ts, lower better)
sorted 1us 1.80 4.86 4.95
sorted 1ms 1.81 5.71 5.21
sorted 1s 1.90 5.78 5.23
1ms, ms-quant 1.81 8.37 6.16
1s, s-quant 1.88 9.13 5.92
batched 1k/s 1.69 5.12 4.89
unsorted 1h 2.12 6.38 5.33
There is simply no competition. On encoding/decoding performance DBP is
multiple times faster. DBP beats lz4 on size on every distribution. DBP
loses size vs zstd on distributions with many trailing zeros.
On Fri, Jul 10, 2026 at 10:04 AM Antoine Pitrou <[email protected]> wrote:
>
> Le 10/07/2026 à 08:37, Alkis Evlogimenos via dev a écrit :
> > The 12-byte ints were chosen because they are enough to cover the SQL
> range
> > with up to femtosecs precision. This saves 4 bytes per timestamp if they
> > are encoded PLAIN.
>
> If they are encoded PLAIN *and* uncompressed, which must be an uncommon
> choice.
>
> And to repeat my question: why not FLBA<N> instead of hardcoding 12 in
> the spec?
>
> > BYTE_STREAM_SPLIT is unimpressive. It improves a general compressor's
> > compression ratio but general compression is generally very slow.
>
> I'm not sure what your expectations are wrt. "slow" vs. "fast".
> But LZ4 decompression is typically several GB/s.
>
> Regards
>
> Antoine.
>
>
>
