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

From Christopher Browne
Subject Re: Experimental patch for inter-page delay in VACUUM
Date
Msg-id 60ad7h70os.fsf@dev6.int.libertyrms.info
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  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
pgman@candle.pha.pa.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)


pgsql-hackers by date:

Previous
From: Kurt Roeckx
Date:
Subject: Re: Annotated release notes
Next
From: Stephan Szabo
Date:
Subject: Re: 7.4RC1 planned for Monday