Re: Number of attributes in HeapTupleHeader

From: Neil Conway <nconway(at)klamath(dot)dyndns(dot)org>
To: "Hiroshi Inoue" <Inoue(at)tpf(dot)co(dot)jp>
Cc: mkoi-pg(at)aon(dot)at, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Number of attributes in HeapTupleHeader
Date: 2002-05-06 00:59:06
Message-ID: 20020505205906.4224d66e.nconway@klamath.dyndns.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, 6 May 2002 08:44:27 +0900
"Hiroshi Inoue" <Inoue(at)tpf(dot)co(dot)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(at)rogers(dot)com>
PGP Key ID: DB3C29FC

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Lamar Owen 2002-05-06 01:13:26 Re: STILL LACKING: CVS tag for release 7.2.1
Previous Message Hiroshi Inoue 2002-05-05 23:44:27 Re: Number of attributes in HeapTupleHeader