> WAL would provide the framework to do something like that, but I still
> say it'd be a bad idea.  What you're describing is
> irrevocable-once-it-starts DROP COLUMN; there is no way to 
> roll it back.
> We're trying to get rid of statements that act that way, not add more.

Yes.

> I am not convinced that a 2x penalty for DROP COLUMN is such a huge
> problem that we should give up all the normal safety features of SQL
> in order to avoid it.  Seems to me that DROP COLUMN is only a 
> big issue during DB development, when you're usually working with 
> relatively small amounts of test data anyway.

Here I don't agree, the statement can also be used for an application version
upgrade.  Thus seen in SAP/R3 with tables > 30 Gb.

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) 

Andreas 

Thu, 12 Oct 2000 16:23:35 +0200
Zeugswetter Andreas SB <ZeugswetterA@wien.spardat.at>
AW: ALTER TABLE DROP COLUMN 
Zeugswetter Andreas SB <ZeugswetterA@wien.spardat.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.

			regards, tom lane

Thu, 12 Oct 2000 10:38:37 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: AW: ALTER TABLE DROP COLUMN 
On Thu, 12 Oct 2000, Tom Lane wrote:

> Zeugswetter Andreas SB <ZeugswetterA@wien.spardat.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?  Maybe change the stored
value of the deleted field as some internal value that, when vacuum, or
any other operation, sees it, it 'ignores' that field?  maybe something
that when you do an 'alter table drop', it effectively does an UPDATE on
that field to set it to the 'drop column' value?


Thu, 12 Oct 2000 15:06:43 -0300 (ADT)
The Hermit Hacker <scrappy@hub.org>
Re: AW: ALTER TABLE DROP COLUMN 
The Hermit Hacker <scrappy@hub.org> writes:
> On Thu, 12 Oct 2000, Tom Lane wrote:
>> Zeugswetter Andreas SB <ZeugswetterA@wien.spardat.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

Thu, 12 Oct 2000 14:55:50 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: AW: ALTER TABLE DROP COLUMN 
On Thu, 12 Oct 2000, Tom Lane wrote:

> The Hermit Hacker <scrappy@hub.org> writes:
> > On Thu, 12 Oct 2000, Tom Lane wrote:
> >> Zeugswetter Andreas SB <ZeugswetterA@wien.spardat.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. 

what does/would it take to implement this?



Thu, 12 Oct 2000 20:06:16 -0300 (ADT)
The Hermit Hacker <scrappy@hub.org>
Re: AW: ALTER TABLE DROP COLUMN 
Tom Lane wrote:
> 
> Zeugswetter Andreas SB <ZeugswetterA@wien.spardat.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.

Perhaps he means some kind of off-line cleanup tool, that has only the 
requirement of being able to continue from where it left off (or
crashed) ?

It could be useful in some cases (like removing a column on saturday
from a 
terabyte-sized file that is used only on weekdays :)

----------
Hannu

Fri, 13 Oct 2000 16:53:08 +0300
Hannu Krosing <hannu@tm.ee>
Re: AW: ALTER TABLE DROP COLUMN