Manfred Koizar <[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html