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

Re: Experimental patch for inter-page delay in VACUUM

From: Christopher Browne <cbbrowne(at)libertyrms(dot)info>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Experimental patch for inter-page delay in VACUUM
Date: 2003-10-31 17:54:11
Message-ID: 60ad7h70os.fsf@dev6.int.libertyrms.info (view raw or flat)
Thread:
Lists: pgsql-hackers
pgman(at)candle(dot)pha(dot)pa(dot)us (Bruce Momjian) writes:
> Tom Lane wrote:
>> 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?

If the vacuum is deferred, that merely means that you put off the
"slow to a crawl" until a bit later.  It is a given that the system
will slow to a crawl for the duration of the vacuum; you are merely
putting it off a bit.

The advantage of the per-page delay is that performance is not being
"totally hammered" by the vacuum.  If things are so busy that it's an
issue, the system is liable to "limp somewhat," but that's not as bad
as what we see now, where VACUUM and other activity are 'dueling' for
access to I/O.  Per-page delay means that VACUUM mostly defers to the
other activity, limiting how badly it hurts other performance.
-- 
output = reverse("ofni.smrytrebil" "@" "enworbbc")
<http://dev6.int.libertyrms.com/>
Christopher Browne
(416) 646 3304 x124 (land)

In response to

Responses

pgsql-hackers by date

Next:From: Stephan SzaboDate: 2003-10-31 18:15:51
Subject: Re: 7.4RC1 planned for Monday
Previous:From: Kurt RoeckxDate: 2003-10-31 17:39:47
Subject: Re: [HACKERS] Annotated release notes

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