Re: Number of attributes in HeapTupleHeader

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Manfred Koizar <mkoi-pg(at)aon(dot)at>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Number of attributes in HeapTupleHeader
Date: 2002-05-05 23:41:00
Message-ID: 18717.1020642060@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Manfred Koizar <mkoi-pg(at)aon(dot)at> writes:
> Currently there's an int16 t_natts in HeapTupleHeaderData. This
> number is stored on disk for every single tuple. Assuming that the
> number of attributes is constant for all tuples of one relation we
> have a lot of redundancy here.

... but that's a false assumption.

No, I don't think removing 2 bytes from the header is worth making
ALTER TABLE ADD COLUMN orders of magnitude slower. Especially since
the actual savings will be *zero*, unless you can find another 2 bytes
someplace.

> If this is doable, we arrive at 6 bytes. And what works for t_natts,
> should also work for t_hoff; that's another byte. Are we getting
> nearer?

Sorry, you used up your chance at claiming that t_hoff is dispensable.
If we apply your already-submitted patch, it isn't.

The bigger picture here is that the more redundancy we squeeze out
of tuple headers, the more fragile the table data structure becomes.
Even if we could remove t_natts at zero runtime cost, I'd be concerned
about the implications for reliability (ie, ability to detect
inconsistencies) and post-crash data reconstruction. I've spent enough
time staring at tuple dumps to be fairly glad that we don't run the
data through a compressor ;-)

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Hiroshi Inoue 2002-05-05 23:44:27 Re: Number of attributes in HeapTupleHeader
Previous Message Tom Lane 2002-05-05 23:21:31 Re: Native Windows, Apache Portable Runtime