Re: Number of attributes in HeapTupleHeader
От | Neil Conway |
---|---|
Тема | Re: Number of attributes in HeapTupleHeader |
Дата | |
Msg-id | 20020505205906.4224d66e.nconway@klamath.dyndns.org обсуждение исходный текст |
Ответ на | Re: Number of attributes in HeapTupleHeader ("Hiroshi Inoue" <Inoue@tpf.co.jp>) |
Ответы |
Re: Number of attributes in HeapTupleHeader
Re: Number of attributes in HeapTupleHeader |
Список | 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 по дате отправления: