Re: ALTER TABLE DROP COLUMN

From: The Hermit Hacker <scrappy(at)hub(dot)org>
To: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)jp>, PostgreSQL Development <pgsql-hackers(at)postgreSQL(dot)org>
Subject: Re: ALTER TABLE DROP COLUMN
Date: 2000-10-09 21:04:15
Message-ID: Pine.BSF.4.21.0010091801260.625-100000@thelab.hub.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, 9 Oct 2000, Bruce Momjian wrote:

> > On Mon, 9 Oct 2000, Tom Lane wrote:
> >
> > > The Hermit Hacker <scrappy(at)hub(dot)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?

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2000-10-09 21:16:21 Re: ALTER TABLE DROP COLUMN
Previous Message Bruce Momjian 2000-10-09 20:46:14 Re: OSF/1/Digital UNIX/Tru64 UNIX spinlock code