Re: Number of attributes in HeapTupleHeader - Mailing list pgsql-hackers

From Neil Conway
Subject Re: Number of attributes in HeapTupleHeader
Date
Msg-id 20020505205906.4224d66e.nconway@klamath.dyndns.org
Whole thread Raw
In response to Re: Number of attributes in HeapTupleHeader  ("Hiroshi Inoue" <Inoue@tpf.co.jp>)
Responses Re: Number of attributes in HeapTupleHeader  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: Number of attributes in HeapTupleHeader  ("Christopher Kings-Lynne" <chriskl@familyhealth.com.au>)
List pgsql-hackers
On Mon, 6 May 2002 08:44:27 +0900
"Hiroshi Inoue" <Inoue@tpf.co.jp> wrote:
> > -----Original Message-----
> > From: Manfred Koizar
> > 
> > If there is interest in reducing on-disk tuple header size and I have
> > not missed any strong arguments against dropping t_natts, I'll
> > investigate further.  Comments?
> 
> If a dbms is proper, it prepares a mechanism from the first
> to handle ADD COLUMN without touching the tuples. If the
> machanism is lost(I believe so) by removing t_natts, I would
> say good bye to PostgreSQL.

IMHO, the current ADD COLUMN mechanism is a hack. Besides requiring
redundant on-disk data (t_natts), it isn't SQL compliant (because
default values or NOT NULL can't be specified), and depends on
a low-level kludge (that the storage system will return NULL for
any attnums > the # of the attributes stored in the tuple).

While instantaneous ADD COLUMN is nice, I think it's counter-
productive to not take advantage of a storage space optimization
just to preserve a feature that is already semi-broken.

Cheers,

Neil

-- 
Neil Conway <neilconway@rogers.com>
PGP Key ID: DB3C29FC


pgsql-hackers by date:

Previous
From: "Hiroshi Inoue"
Date:
Subject: Re: Number of attributes in HeapTupleHeader
Next
From: Lamar Owen
Date:
Subject: Re: STILL LACKING: CVS tag for release 7.2.1