Tom Lane wrote:
> "Heikki Linnakangas" <heikki@enterprisedb.com> writes:
>> Tom Lane wrote:
>>> Then you don't remember far enough --- either the HeapTupleHeader change
>>> or the varvarlena change would be enough to prevent that. For that
>>> matter, the pd_flags header field that the patch is already relying on
>>> is new for 8.3.
>
>> Yeah, those changes will need to be dealt with in the conversion. But
>> none of the changes this far have increased the on-disk size. Adding a
>> new field to page header means that in some corner cases it might not be
>> possible to convert a page from old format to the new one because the
>> data no longer fits.
>
> Counting on my fingers, it seems that the 4-byte savings in
> HeapTupleHeader size would guarantee that adding 4 bytes to the page
> header wouldn't kill you.
It depends on the alignment of the data and null-bitmap. For example:
- a platform with 8 bytes alignment
- the table has 9 columns
- every tuple on the page has a null bitmap
- there is zero bytes left on the page
- no tuples where varvarlen frees up space
The header size after alignment is MAXALIGN(23+2) = 32. Which is the
same as before combo cid, MAXALIGN(27+2) = 32. It's a corner-case, but
it's possible.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
