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 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
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)
From | Date | Subject | |
---|---|---|---|
Next Message | Stephan Szabo | 2003-10-31 18:15:51 | Re: 7.4RC1 planned for Monday |
Previous Message | Kurt Roeckx | 2003-10-31 17:39:47 | Re: [HACKERS] Annotated release notes |