Hi,
On 2021-08-04 09:31:25 -0400, Robert Haas wrote:
> This is pretty integer-centric, though. If your pass-by-value type is
> storing timestamps, for example, they're not likely to be especially
> close to zero. Since a 64-bit address is pretty big, perhaps they're
> still close enough to zero that this will work out to a win, but I
> don't know, that seems a bit cheesy.
Yea, that's fair. The really bad™ example probably is negative numbers - which
wouldn't be easy to do something about in a datatype agnostic way.
> I grant that it could work out to a win -- pass-by-value data types whose
> distribution is very different from what's typical for integers, or for that
> matter columns full of integers that all happen to be toward the extreme
> values the data type can store, are probably not that common.
It'd work out as a wash for common timestamps:
./varint_test -u 681413261095983
processing unsigned
unsigned: 681413261095983
input bytes: 00 02 6b bd e3 5f 74 2f
8 output bytes: 01 02 6b bd e3 5f 74 2f
decoded: 681413261095983
I don't think there's many workloads where plain integers would skew extreme
enough for it to work out to a loss often enough to matter. But:
> I just don't really like making such assumptions on a system-wide basis (as
> opposed to a per-datatype basis where it's easier to reason about the
> consequences).
I'd not at all be opposed to datatypes having influence over the on-disk
encoding. I was just musing about a default heuristic that could make sense. I
do think you'd want something that chooses the encoding for one pg_attribute
values based on preceding columns.
Greetings,
Andres Freund
