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

Experimental patch for inter-page delay in VACUUM

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: pgsql-hackers(at)postgreSQL(dot)org
Subject: Experimental patch for inter-page delay in VACUUM
Date: 2003-10-31 02:40:33
Message-ID: 5464.1067568033@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
Attached is an extremely crude prototype patch for making VACUUM delay
by a configurable amount between pages, in hopes of throttling its disk
bandwidth consumption.  By default, there is no delay (so no change in
behavior).  In some quick testing, setting vacuum_page_delay to 10
(milliseconds) seemed to greatly reduce a background VACUUM's impact
on pgbench timing on an underpowered machine.  Of course, it also makes
VACUUM a lot slower, but that's probably not a serious concern for
background VACUUMs.

I am not proposing this for application to the master sources yet, but
I would be interested to get some feedback from people who see serious
performance degradation while VACUUM is running.  Does it help?  What do
you find to be a good setting for vacuum_page_delay?

Assuming that this is found to be useful, the following issues would
have to be dealt with before the patch would be production quality:

1. The patch depends on usleep() which is not present on all platforms,
   and may have unwanted side-effects on SIGALRM processing on some
   platforms.  We'd need to replace that with something else, probably
   a select() call.

2. I only bothered to insert delays in the processing loops of plain
   VACUUM and btree index cleanup.  VACUUM FULL and cleanup of non-btree
   indexes aren't done yet.

3. No documentation...

The patch is against CVS tip, but should apply cleanly to any recent
7.4 beta.  You could likely adapt it to 7.3 without much effort.

			regards, tom lane

Responses

pgsql-hackers by date

Next:From: Marc G. FournierDate: 2003-10-31 02:42:42
Subject: Re: 7.4RC1 planned for Monday
Previous:From: Bruce MomjianDate: 2003-10-31 01:46:32
Subject: Re: PQunescapeBytea code

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