Re: Tuple data

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)jp>
Cc: Hannu Krosing <hannu(at)tm(dot)ee>, Michael Richards <miker(at)interchange(dot)ca>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Tuple data
Date: 2000-12-18 01:05:40
Message-ID: 8405.977101540@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)jp> writes:
>> Tom Lane wrote:
>>>>> ALTER ADD COLUMN doesn't touch any tuples, and you're right that it's
>>>> critically dependent on heap_getattr returning NULL when an attribute
>>>> beyond the number of attributes actually present in a tuple is accessed.
>>>> That's a fragile and unclean implementation IMHO --- see past traffic
>>>> on this list.

> I don't remember the traffic either.
> IIRC,I objected to Tom at this point in pgsql-bugs recently.

That was the traffic I was recalling ;-)

> I think it's very important for dbms that ALTER ADD COLUMN
> touches tuples as less as possible.

I disagree. The existing ADD COLUMN implementation only works for
appending columns at the end of tuples; it can't handle inserting
a column. To make it usable for inherited tables requires truly
horrendous kluges (as you well know). IMHO we'd be far better off
to rewrite ADD COLUMN so that it does go through and change all the
tuples, and then we could get rid of the hackery that tries --- not
very successfully --- to deal with inconsistent column orders between
parent and child tables.

I have a similar opinion about DROP COLUMN ...

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Richards 2000-12-18 01:37:03 Re: Tuple data
Previous Message Hiroshi Inoue 2000-12-18 00:41:39 Re: TOAST-table vacuuming (was Re: Idea for reducing planning time)