Tom Lane wrote: > "Heikki Linnakangas" <[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster
