Re: Number of attributes in HeapTupleHeader

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

On Sun, 05 May 2002 19:41:00 -0400, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
wrote:
>No, I don't think removing 2 bytes from the header is worth making
>ALTER TABLE ADD COLUMN orders of magnitude slower.

I agree. And I'll not touch the code, if my modifications break an
existing feature.

For now I rather work on a patch to eliminate one of the 4
Transaction/CommandIds per tuple as discussed in another thread. This
will at least benefit those, who run PG on machines with 4 byte
alignment.

>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 ;-)

Well, that's a matter of taste. You are around for several years and
you are used to having natts in each tuple. Others might wish to have
more redundant metadata in tuple headers, or less. It's hard to draw
a sharp line here.
Servus
Manfred

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Lee Kindness 2002-05-08 15:36:15 Path to PostgreSQL portabiliy
Previous Message Enke, Michael 2002-05-08 14:54:55 Re: Bug #659: lower()/upper() bug on ->multibyte<- DB