Skip site navigation (1) Skip section navigation (2)

Re: Experimental patch for inter-page delay in VACUUM

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Matthew T(dot) O'Connor" <matthew(at)zeut(dot)net>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Experimental patch for inter-page delay in VACUUM
Date: 2003-10-31 05:53:14
Message-ID: 7473.1067579594@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
"Matthew T. O'Connor" <matthew(at)zeut(dot)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.

			regards, tom lane

In response to

Responses

pgsql-hackers by date

Next:From: Joe ConwayDate: 2003-10-31 05:54:10
Subject: Re: Annotated release notes
Previous:From: Tom LaneDate: 2003-10-31 05:43:48
Subject: Re: Annotated release notes

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group