Re: Experimental patch for inter-page delay in VACUUM

Bruce Momjian <pgman@candle.pha.pa.us>

From: Bruce Momjian <pgman@candle.pha.pa.us>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: "Matthew T. O'Connor" <matthew@zeut.net>, pgsql-hackers@postgresql.org
Date: 2003-10-31T16:42:20Z
Lists: pgsql-hackers
Tom Lane wrote:
> "Matthew T. O'Connor" <matthew@zeut.net> writes:
> > Tom Lane wrote:
> >> 2. I only bothered to insert delays in the processing loops of plain
> >> VACUUM and btree index cleanup.  VACUUM FULL and cleanup of non-btree
> >> indexes aren't done yet.
> >> 
> > I thought we didn't want the delay in vacuum full since it locks things 
> > down, we want vacuum full to finish ASAP.  As opposed to normal vacuum 
> > which would be fired by the autovacuum daemon.
> 
> My thought was that it'd be up to the user to set vacuum_page_delay
> appropriately for what he is doing.  It might or might not ever make
> sense to use a nonzero delay in VACUUM FULL, but the facility should be
> there.  (Since plain and full VACUUM share the same index cleanup code,
> it would take some klugery to implement a policy of "no delays for
> VACUUM FULL" anyway.)
> 
> Best practice would likely be to leave the default vacuum_page_delay at
> zero, and have the autovacuum daemon set a nonzero value for vacuums it
> issues.

What is the advantage of delaying vacuum per page vs. just doing vacuum
less frequently?

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073