Re: Vacuum only with 20% old tuples

Tom Lane wrote:
> 
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > I suggest that we change vacuum to only move remove tuples if there is
> > more than 20% expired tuples.
> 
> > When we do vacuum, we drop all indexes and recreate them.
> 
> > This fixes the complaint about vacuum slowness when there are many
> > expired rows in the table.  We know this is causes by excessive index
> > updates.  It allows indexes to shrink (Jan pointed this out to me.)  And
> > it fixes the TOAST problem with TOAST values in indexes.
> 
> We can't "drop and recreate" without a solution to the relation
> versioning issue (unless you are prepared to accept a nonfunctional
> database after a failure partway through index rebuild on a system
> table).  I think we should do this, but it's not all that simple...
> 
> I do not see what your 20% idea has to do with this, though, nor
> why it's a good idea.  If I've told the thing to vacuum I think
> it should vacuum.  20% of a big table could be a lot of megabytes,
> and I don't want some arbitrary decision in the code about whether
> I can reclaim that space or not.

I can see some value in having a _configurable_ threshold %age of
deletes before vacuum kicked in and attempted to shrink table/index
on-disk file sizes.  This would let the end-user decide, and 20% is
probably a reasonable default, but if it isn't then changing a default
is easier to do down the track.

I can also see that it could be done with (perhaps) a modification to
VACUUM syntax, say:VACUUM [VERBOSE] [SHRINK] ...

And I believe that the whole thing will go better if ANALYZE is taken
_out_ of vacuum, as was discussed on this list a month or two ago.

Cheers,                Andrew.
-- 
_____________________________________________________________________           Andrew McMillan, e-mail:
Andrew@cat-it.co.nz
Catalyst IT Ltd, PO Box 10-225, Level 22, 105 The Terrace, Wellington
Me: +64 (21) 635 694, Fax: +64 (4) 499 5596, Office: +64 (4) 499 2267