Re: Experimental patch for inter-page delay in VACUUM - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: Experimental patch for inter-page delay in VACUUM
Date
Msg-id 200310311642.h9VGgKW29891@candle.pha.pa.us
Whole thread Raw
In response to Re: Experimental patch for inter-page delay in VACUUM  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Experimental patch for inter-page delay in VACUUM
Re: Experimental patch for inter-page delay in VACUUM
List 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,
Pennsylvania19073
 


pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: Call for port reports
Next
From: Jan Wieck
Date:
Subject: Re: 7.4RC1 planned for Monday