Re: Experimental patch for inter-page delay in VACUUM

Jan Wieck <janwieck@yahoo.com>

From: Jan Wieck <JanWieck@Yahoo.com>
To: Bruce Momjian <pgman@candle.pha.pa.us>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, "Matthew T. O'Connor" <matthew@zeut.net>, pgsql-hackers@postgresql.org
Date: 2003-10-31T17:22:50Z
Lists: pgsql-hackers
Bruce Momjian wrote:

> 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?

It gives regular backends more time to "retouch" the pages they actually 
need before they fall off the end of the LRU list.


Jan

-- 
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== JanWieck@Yahoo.com #