> 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?
Agreed, let's keep this discussion focused to extended-precision timestamps. We can have separate discussions on encodings.. > And conversely, I do not see what we get out of mandating FLBA<12>. :-) FLBA<N> works, but I would be concerned about added complexity on the reader side as I assume engines will want to use compact data types to represent timestamps as much as possible, so they'd have to manage different data types for different values of N. It's also not clear to me what the advantage is of, say, 64-byte nanosecond precision. If we feel 12 is not enough / there are enough use cases coming from non-SQL that need a larger range, we could change this to 16 or some other value. -- Divjot On Fri, Jul 10, 2026 at 11:16 AM Antoine Pitrou <[email protected]> wrote: > > 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. > > >
