From: | "Hiroshi Inoue" <Inoue(at)tpf(dot)co(dot)jp> |
---|---|
To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "Bruce Momjian" <pgman(at)candle(dot)pha(dot)pa(dot)us>, "PostgreSQL-development" <pgsql-hackers(at)postgreSQL(dot)org> |
Subject: | RE: Vacuum only with 20% old tuples |
Date: | 2000-07-12 04:58:17 |
Message-ID: | 002701bfebbd$caa1a240$2801007e@tpf.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> -----Original Message-----
> From: Tom Lane [mailto:tgl(at)sss(dot)pgh(dot)pa(dot)us]
>
> "Hiroshi Inoue" <Inoue(at)tpf(dot)co(dot)jp> writes:
> >> Basically what I want here is to build the new index relation as
> >> a new file (set of files, if large) and then atomically commit it
> >> as the new version of the index.
>
> > Hmm,your plan seems to need WAL.
> > We must postpone to build indexes until the end of tuple moving
> > in vacuum. Once tuple moving started,the consistency between
> > heap and indexes would be broken. Currently(without WAL) this
> > inconsistency could never be recovered in case of rollback.
>
> Why? The same commit that makes the new index valid would make the
> tuple movements valid.
Oops,I rememered I wasn't correct. Certainly it's not so dangerous as
I wrote. But there remains a possibilty that index tuples would point to
cleaned heap blocks unless we delete index tuples for those heap blocks.
Cleaned blocks would be reused by UPDATE operation.
Regards.
Hiroshi Inoue
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2000-07-12 05:21:00 | Re: Performance problem in aset.c |
Previous Message | Bruce Momjian | 2000-07-12 04:28:46 | Re: Connection pooling. |