Re: AW: ALTER TABLE DROP COLUMN

The Hermit Hacker <scrappy(at)hub(dot)org> writes:
> On Thu, 12 Oct 2000, Tom Lane wrote:
>> Zeugswetter Andreas SB <ZeugswetterA(at)wien(dot)spardat(dot)at> writes:
>>>> My conclusion would be that we need both:
>>>> 1. a fast system table only solution with physical/logical column id
>>>> 2. a tool that does the cleanup (e.g. vacuum)
>>
>> But the peak space usage during cleanup must still be 2X.

> Is there no way of doing this such that we have N tuple types in the
> table? So that UPDATE/INSERTs are minus the extra column, while the old
> ones just have that column marked as deleted?

If we bite the bullet to the extent of supporting a distinction between
physical and logical column numbers, then ISTM there's no strong need
to do any of this other stuff at all. I'd expect that an inserted or
updated tuple would have a NULL in any physical column position that
doesn't have an equivalent logical column, so the space cost is minimal
(zero, in fact, if there are any other NULLs in the tuple). Over time
the space occupied by deleted-column data would gradually go away as
tuples got updated.

I really don't see why we're expending so much discussion on ways to
reformat all the tuples at once. It can't be done cheaply and I see
no real reason to do it at all, so it seems like we have many
more-profitable problems to work on.

regards, tom lane