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