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