Re: [HACKERS] Index recreation in vacuum

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: Dmitry Samersoff <dms(at)wplus(dot)net>, Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)jp>, pgsql-hackers <pgsql-hackers(at)postgreSQL(dot)org>
Subject: Re: [HACKERS] Index recreation in vacuum
Date: 2000-01-18 22:32:55
Message-ID: 2246.948234775@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> The beauty of doing a temp index while keeping the old one is that you
> can recover right away, and maybe allow the old index to be used while
> you vacuum?

Huh? You've got the whole table locked exclusively for the duration
of the vacuum anyway.

In fact, the instant that vacuum does its internal commit, the old index
contents are actually *wrong*, and there is no possible value in keeping
them after that. Might as well blow them away and recover the disk
space for use in constructing the new indexes.

Also, I agree with Dmitry's concern about peak disk space usage. If
we are rebuilding large btree indexes then we are going to see about a
2X-normal peak usage anyway, for the sort temp file and the new index.
Making it 3X instead is just asking for trouble. Especially since,
if you fail to rebuild the index, you are left with a corrupt index;
it doesn't agree with the vacuumed table...

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2000-01-18 22:36:23 Re: [HACKERS] Index recreation in vacuum
Previous Message Bruce Momjian 2000-01-18 20:45:47 Re: [HACKERS] Index recreation in vacuum