From: | "Hiroshi Inoue" <Inoue(at)tpf(dot)co(dot)jp> |
---|---|
To: | "Dmitry Samersoff" <dms(at)wplus(dot)net> |
Cc: | "Bruce Momjian" <pgman(at)candle(dot)pha(dot)pa(dot)us>, "pgsql-hackers" <pgsql-hackers(at)postgreSQL(dot)org> |
Subject: | RE: [HACKERS] Index recreation in vacuum |
Date: | 2000-01-19 23:19:26 |
Message-ID: | 000901bf62d3$a0bfa940$2801007e@tpf.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> -----Original Message-----
> From: Dmitry Samersoff [mailto:dms(at)wplus(dot)net]
>
> Hiroshi Inoue wrote:
> > > > Yes,I believe so. It's necessary to keep consistency between heap
> > > > table and indexes even in case of abort/crash.
> > > > As far as I see,it has been a big charge for vacuum.
> > >
> > > OK, how about making a copy of the heap table before starting vacuum,
> > > moving all the tuples in that copy, create new index, and
> then move the
> > > new heap and indexes over the old version. We already have
> an exclusive
> > > lock on the table. That would be 100% reliable, with the disadvantage
> > > of using 2x the disk space. Seems like a big win.
> > >
> >
> > I heard from someone that old vacuum had been like so.
> > Probably 2x disk space for big tables was a big disadvantage.
>
> Yes, It is critical.
>
> How about sequence like this:
>
> * Drop indices (keeping somewhere index descriptions)
> * vacuuming table
> * recreate indices
>
Yes,my idea is almost same.
I won't drop indices but make them invisible in a sense.
Regards.
Hiroshi Inoue
Inoue(at)tpf(dot)co(dot)jp
From | Date | Subject | |
---|---|---|---|
Next Message | Keith Parks | 2000-01-19 23:41:21 | initdb problems on Solaris |
Previous Message | Tom Lane | 2000-01-19 22:29:11 | Re: [HACKERS] Cannot compile psql |