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?
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 |