Re: Another idea for dealing with cmin/cmax

ITAGAKI Takahiro wrote:
> However, I think our next goal to shrink the headers is 16 bytes. The
> headers
> become 23 bytes using phantom cids and we are limited by alignments,
> so we will
> have no more advantages unless we delete extra 7 bytes in the headers.
> ...and it seems to be very difficult.

Yeah, I thought about that too earlier.

If we get rid of VACUUM FULL, or replace it with something that doesn't
need xvac, and keep cmin and cmax in backend-private storage, we could
get rid of the overlayed t_field4, which is 4 bytes. Then we're down to
19 bytes.

We could get rid of t_hoff, because we should always be able to
calculate the header size. Then we're down to 18 bytes.

There's currently 15 bits in use in the infomask. After we remove the
HEAP_MOVED_* fields that we don't need without VACUUM FULL, that's down
to 13 bits. t_natts only needs 11 bits, because MaxHeapAttributeNumber
is 1600. We could move 5 of the bits in infomask to the high 5 bits of
t_natts, and save one byte.

We're now down to 17 bytes. That's as far as I got.

So it seems we could shave off some bytes, but we still can't get down
to 16. And the changes needed in total would be quite massive.

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com