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

From Ang Chin Han
Subject Re: Experimental patch for inter-page delay in VACUUM
Date
Msg-id 3FA7261B.1060005@bytecraft.com.my
Whole thread Raw
In response to Re: Experimental patch for inter-page delay in VACUUM  (Christopher Browne <cbbrowne@acm.org>)
Responses Re: Experimental patch for inter-page delay in VACUUM  (Jan Wieck <JanWieck@Yahoo.com>)
Re: Experimental patch for inter-page delay in VACUUM  ("Matthew T. O'Connor" <matthew@zeut.net>)
List pgsql-hackers
Christopher Browne wrote:
> Centuries ago, Nostradamus foresaw when "Stephen" <jleelim@xxxxxxx.com> would write:
> 
>>As it turns out. With vacuum_page_delay = 0, VACUUM took 1m20s (80s)
>>to complete, with vacuum_page_delay = 1 and vacuum_page_delay = 10,
>>both VACUUMs completed in 18m3s (1080 sec). A factor of 13 times! 
>>This is for a single 350 MB table.
> 
> 
> While it is unfortunate that the minimum quanta seems to commonly be
> 10ms, it doesn't strike me as an enormous difficulty from a practical
> perspective.

If we can't lower the minimum quanta, we could always vacuum 2 pages 
before sleeping 10ms, effectively sleeping 5ms.

Say,
vacuum_page_per_delay = 2
vacuum_time_per_delay = 10

What would be interesting would be pg_autovacuum changing these values 
per table, depending on current I/O load.

Hmmm. Looks like there's a lot of interesting things pg_autovacuum can do:
1. When on low I/O load, running multiple vacuums on different, smaller 
tables on full speed, careful to note that these vacuums will increase 
the I/O load as well.
2. When on high I/O load, vacuum big, busy tables slowly.


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: 7.4RC1 tag'd, branched and bundled ...
Next
From: Jan Wieck
Date:
Subject: Re: 7.4RC1 failed to build on Linux