On Fri, Dec 4, 2009 at 12:57 PM, Simon Riggs <simon@2ndquadrant.com> wrote:
> On Fri, 2009-12-04 at 07:54 -0500, Bruce Momjian wrote:
>
>> > I should also point out that removing 4 bits from the tuple header would
>> > allow us to get rid of t_infomask2, reducing tuple length by a further 2
>> > bytes.
>>
>> Wow, that is a nice win. Does alignment allow us to actually use that
>> space?
>
> It would mean that tables up to 24 columns wide would still be 24 bytes
> wide, whereas >8 columns now has to fit in 32 bytes. So in practical
> terms most tables would benefit in your average database.
I don't think getting rid of infomask2 wins us 2 bytes so fast. The
rest of those two bytes is natts which of course we still need.
If we lose vacuum full then the table's open for reducing the width of
command id too if we need more bits. If we do that and we moved
everything we could to the line pointers including ctid we might just
be able to squeeze the tuple overhead down to 16 bytes. That would win
8 bytes per tuple for people with no null columns or with nulls and a
total of 9-64 columns but if they have 1-8 columns and any are null it
would actually consume more space. But it looks to me like it would be
very very tight and require drastic measures -- I think we would be
left with something like 11 bits for commandid and no spare bits in
the tuple header at all.
--
greg
