Re: ALTER TABLE DROP COLUMN - Mailing list pgsql-hackers

From The Hermit Hacker
Subject Re: ALTER TABLE DROP COLUMN
Date
Msg-id Pine.BSF.4.21.0010091801260.625-100000@thelab.hub.org
Whole thread Raw
In response to Re: ALTER TABLE DROP COLUMN  (Bruce Momjian <pgman@candle.pha.pa.us>)
Responses Re: ALTER TABLE DROP COLUMN  (Bruce Momjian <pgman@candle.pha.pa.us>)
Re: ALTER TABLE DROP COLUMN  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Mon, 9 Oct 2000, Bruce Momjian wrote:

> > On Mon, 9 Oct 2000, Tom Lane wrote:
> > 
> > > The Hermit Hacker <scrappy@hub.org> writes:
> > > >> What happens if you crash partway through?
> > > 
> > > > what happens if you crash partway through a vacuum?
> > > 
> > > Nothing.  Vacuum is crash-safe.  ALTER TABLE should be too.
> > 
> > Sorry, that's what I meant ... why should marking a column as 'deleted'
> > and running a 'vacuum' to clean up the physical table be any less
> > crash-safe?  
> 
> It is not.  The only downside is 2x disk space to make new versions of
> the tuple.

huh?  vacuum moves/cleans up tuples, as well as compresses them, so that
the end result is a smaller table then what it started with, at/with very
little increase in the total size/space needed to perform the vacuum ...

if we reduced vacuum such that it compressed at the field level vs tuple,
we could move a few tuples to the end of the table (crash safe) and then
move N+1 to position 1 minus that extra field.  If we mark the column as
being deleted, then if the system crashes part way through, it should be
possible to continue after the system is brought up, no?




pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: OSF/1/Digital UNIX/Tru64 UNIX spinlock code
Next
From: Bruce Momjian
Date:
Subject: Re: ALTER TABLE DROP COLUMN