RE: [HACKERS] Index recreation in vacuum - Mailing list pgsql-hackers

From Hiroshi Inoue
Subject RE: [HACKERS] Index recreation in vacuum
Date
Msg-id 000201bf621a$6b9baf20$2801007e@tpf.co.jp
Whole thread Raw
In response to Re: [HACKERS] Index recreation in vacuum  (Bruce Momjian <pgman@candle.pha.pa.us>)
Responses Re: [HACKERS] Index recreation in vacuum
List pgsql-hackers
> -----Original Message-----
> From: Bruce Momjian [mailto:pgman@candle.pha.pa.us]
> 
> [Charset iso-8859-1 unsupported, filtering to ASCII...]
> > Hi all,
> > 
> > I'm trying to implement REINDEX command.
> > 
> > REINDEX operation itself is available everywhere and
> > I've thought about applying it to VACUUM.
> 
> That is a good idea.  Vacuuming of indexes can be very slow.
> 
> > .
> > My plan is as follows.
> > 
> > Add a new option to force index recreation in vacuum
> > and if index recreation is specified.
> 
> Couldn't we auto-recreate indexes based on the number of tuples moved by
> vacuum,

Yes,we could probably do it. But I'm not sure the availability of new
vacuum.

New vacuum would give us a big advantage that
1) Much faster than current if vacuum remove/moves many tuples.
2) Does shrink index files

But in case of abort/crash
1) couldn't choose index scan for the table
2) unique constraints of the table would be lost

I don't know how people estimate this disadvantage. 
> 
> > Now I'm inclined to use relhasindex of pg_class to
> > validate/invalidate indexes of a table at once.
> 
> There are a few calls to CatalogIndexInsert() that know the 
> system table they
> are using and know it has indexes, so it does not check that field.  You
> could add cases for that.
>

I think there aren't so many places to check.
I would examine it if my idea is OK.

Regards.

Hiroshi Inoue
Inoue@tpf.co.jp


pgsql-hackers by date:

Previous
From: Alfred Perlstein
Date:
Subject: Re: [HACKERS] gperf anyone?
Next
From: Tatsuo Ishii
Date:
Subject: Re: [HACKERS] date/time problem in v6.5.3 and 7.0.0 ...