Re: Fixed length data types issue

Bruce Momjian <bruce(at)momjian(dot)us> writes:
> * Consider ways of storing rows more compactly on disk
> o Support a smaller header for short variable-length fields?

With respect to the business of having different on-disk and in-memory
representations, we have that already today: see TOAST. It strikes me
that it might be useful to think about solving the problem with a
"second generation toast mechanism". The first generation only worried
about storing large values, but the second generation would also address
the problem of storing small values efficiently.

Or you could think about it as a "second generation varlena". This
mindset would make for a slightly different set of choices about where
the work gets done. I'm not sure which is better.

Either way, I think it would be interesting to consider

(a) length word either one or two bytes, not four. You can't need more
than 2 bytes for a datum that fits in a disk page ...

(b) alignment either one or two bytes, not four. TEXT would be
perfectly happy with 1-byte alignment, but for NUMERIC we might want 2.

I'm inclined to bag the idea of storing the length words separately from
the data proper. Although it probably would make for some marginal gain
in cache efficiency, I don't see any reasonable way at all to fit it
into the current system structure, whereas either the "toast" or "next
gen varlena" approaches seem fairly straightforward. And having to
track an additional pointer inside the inner loops of heap_form_tuple
and heap_deform_tuple could eat up any performance gain anyway.

regards, tom lane