Re: ALTER TABLE DROP COLUMN

Поиск
Список
Период
Сортировка
От The Hermit Hacker
Тема Re: ALTER TABLE DROP COLUMN
Дата
Msg-id Pine.BSF.4.21.0010091801260.625-100000@thelab.hub.org
обсуждение исходный текст
Ответ на Re: ALTER TABLE DROP COLUMN  (Bruce Momjian <pgman@candle.pha.pa.us>)
Ответы Re: ALTER TABLE DROP COLUMN  (Bruce Momjian <pgman@candle.pha.pa.us>)
Re: ALTER TABLE DROP COLUMN  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: OSF/1/Digital UNIX/Tru64 UNIX spinlock code
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: ALTER TABLE DROP COLUMN