Manfred Koizar <mkoi-pg@aon.at> writes:
> Currently there's an int16 t_natts in HeapTupleHeaderData. This
> number is stored on disk for every single tuple. Assuming that the
> number of attributes is constant for all tuples of one relation we
> have a lot of redundancy here.
... but that's a false assumption.
No, I don't think removing 2 bytes from the header is worth making
ALTER TABLE ADD COLUMN orders of magnitude slower. Especially since
the actual savings will be *zero*, unless you can find another 2 bytes
someplace.
> If this is doable, we arrive at 6 bytes. And what works for t_natts,
> should also work for t_hoff; that's another byte. Are we getting
> nearer?
Sorry, you used up your chance at claiming that t_hoff is dispensable.
If we apply your already-submitted patch, it isn't.
The bigger picture here is that the more redundancy we squeeze out
of tuple headers, the more fragile the table data structure becomes.
Even if we could remove t_natts at zero runtime cost, I'd be concerned
about the implications for reliability (ie, ability to detect
inconsistencies) and post-crash data reconstruction. I've spent enough
time staring at tuple dumps to be fairly glad that we don't run the
data through a compressor ;-)
regards, tom lane