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