Le 10/07/2026 à 10:33, Alkis Evlogimenos via dev a écrit :
PLAIN and uncompressed is common for low latency/high performance.
We don't have any stats about Parquet encoding/compression usage, so
I'll take your word for it (though my bet is that most public Parquet
datasets are not PLAIN-uncompressed). :-)
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.
We would get more flexibility on the storage of timestamps, depending on
the magnitude in the input source or even in the source data type (not
all data comes from SQL).
And conversely, I do not see what we get out of mandating FLBA<12>. :-)
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.
Yeah, well, regardless, this is derailing the discussion quite a bit.
This proposal is not about extending DBP to FLBA. Can we keep it on topic?
Regards
Antoine.
