Re: Packed short varlenas, what next?

Gregory Stark <gsstark@mit.edu> writes:
> 2) The choice of encoding for toast pointers. Note that currently they don't
>    actually save *any* space due to the alignment requirements of the OIDs.
>    which seems kind of silly but I didn't see any reasonable way around that.

I was expecting that we'd store them as unaligned and memcpy a toast
pointer into a suitably-aligned local variable any time we wanted to
look at its contents.  Detoasting is expensive enough that that's not
going to add any noticeable percentage time-overhead, and not having to
align toast pointers should be a pretty good percentage space-saving,
seeing that they're only 20-some bytes anyway.

>    One of the details here is that I didn't store the compressed bit anywhere
>    for external toast pointers. I just made the macro compare the rawsize and
>    extsize. If that strikes anyone as evil we could take a byte out of those 3
>    padding bytes for flags and store a compressed flag there.

I believe this is OK since the toast code doesn't compress unless space
is actually saved.  You should put a note in the code that that behavior
is now necessary for correctness, not just a performance tweak.
        regards, tom lane