Re: [HACKERS] Index recreation in vacuum

Поиск
Список
Период
Сортировка
От Bruce Momjian
Тема Re: [HACKERS] Index recreation in vacuum
Дата
Msg-id 200001190308.WAA13965@candle.pha.pa.us
обсуждение исходный текст
Ответ на RE: [HACKERS] Index recreation in vacuum  ("Hiroshi Inoue" <Inoue@tpf.co.jp>)
Список pgsql-hackers
> I heard from someone that old vacuum had been like so.
> Probably 2x disk space for big tables was a big disadvantage.

That's interesting.

> 
> In addition,rename(),unlink(),mv aren't preferable for transaction
> control as far as I see. We couldn't avoid inconsistency using
> those OS functions.

I disagree.  Vacuum can't be rolled back anyway in the sense you can
bring back expire tuples, though I have no idea why you would want to.

You have an exclusive lock on the table.  Putting new heap/indexes in
place that match and have no expired tuples seems like it can not fail
in any situation.

Of course, the buffers of the old table have to be marked as invalid,
but with an exclusive lock, that is not a problem.  I am sure we do that
anyway�in vacuum.

> We have to wait the change of relation file naming if copying
> vacuum is needed.
> Under the spec we need not rename(),mv etc.

Sorry, I don't agree, yet...

--  Bruce Momjian                        |  http://www.op.net/~candle pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026
 


В списке pgsql-hackers по дате отправления:

Предыдущее
От: "Hiroshi Inoue"
Дата:
Сообщение: RE: [HACKERS] Index recreation in vacuum
Следующее
От: Thomas Lockhart
Дата:
Сообщение: Re: Date/time types (Re: [HACKERS] Re: [COMMITTERS] pgsql/src/include/catalog(pg_type.h))