From: | Ang Chin Han <angch(at)bytecraft(dot)com(dot)my> |
---|---|
To: | Christopher Browne <cbbrowne(at)acm(dot)org> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Experimental patch for inter-page delay in VACUUM |
Date: | 2003-11-04 04:07:55 |
Message-ID: | 3FA7261B.1060005@bytecraft.com.my |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Christopher Browne wrote:
> Centuries ago, Nostradamus foresaw when "Stephen" <jleelim(at)xxxxxxx(dot)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.
From | Date | Subject | |
---|---|---|---|
Next Message | Jan Wieck | 2003-11-04 04:28:25 | Re: Experimental patch for inter-page delay in VACUUM |
Previous Message | Tom Lane | 2003-11-04 04:01:15 | Re: 7.4RC1 tag'd, branched and bundled ... |