Tom Lane wrote:
> "Pavan Deolasee" <pavan.deolasee@gmail.com> writes:
>> Yes. The last bit in the t_infomask is used up to mark presence of overflow
>> tuple header. But I believe there are few more bits that can be reused.
>> There are three bits available in the t_ctid field as well (since ip_posid
>> needs maximum 13 bits).
>
> No, you cannot have those bits --- BLCKSZ is not limited to 8K, and even
> if it were, we will not hold still for sticking flag bits into an
> unrelated datatype.
>
> You can probably fix this by inventing multiple context-dependent
> interpretations of t_infomask bits, but that strikes me as a mighty
> ugly and fragile way to proceed.
Yeah, that seems ugly.
I think the best place to grab more bits is the t_natts field. The max
value for that is MaxTupleAttributeNumber == 1664, which fits in 11
bits. That leaves 5 bits for other use. We'll have to replace all direct
access to that field with an accessor macro, but according to grep there
isn't that many files that need to be changed.
> (Actually, the assumption that you can throw an additional back-pointer
> into overflow tuple headers is the worst feature of this proposal in
> that regard --- it's really not that easy to support multiple header
> formats.)
Well, we already have a variable length null bitmap in the header. It
seems quite straightforward to me to add the new field before the null
bitmap. It certainly requires some changes, in particular to places that
access the null bitmap, but it's not an insurmountable effort. Or am I
missing some less obvious consequences?
-- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com