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