Re: ALTER TABLE DROP COLUMN

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: The Hermit Hacker <scrappy(at)hub(dot)org>
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:16:21
Message-ID: 200010092116.RAA16232@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

If it crashes in the middle, some rows have the column removed, and some
do not.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message The Hermit Hacker 2000-10-09 21:36:05 Re: ALTER TABLE DROP COLUMN
Previous Message The Hermit Hacker 2000-10-09 21:04:15 Re: ALTER TABLE DROP COLUMN