Re: Experimental patch for inter-page delay in VACUUM
Jan Wieck <janwieck@yahoo.com>
From: Jan Wieck <JanWieck@Yahoo.com>
To: Bruce Momjian <pgman@candle.pha.pa.us>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, "Matthew T. O'Connor" <matthew@zeut.net>, pgsql-hackers@postgresql.org
Date: 2003-10-31T17:22:50Z
Lists: pgsql-hackers
Bruce Momjian wrote: > Tom Lane wrote: >> "Matthew T. O'Connor" <matthew@zeut.net> writes: >> > Tom Lane wrote: >> >> 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. >> >> >> > I thought we didn't want the delay in vacuum full since it locks things >> > down, we want vacuum full to finish ASAP. As opposed to normal vacuum >> > which would be fired by the autovacuum daemon. >> >> My thought was that it'd be up to the user to set vacuum_page_delay >> appropriately for what he is doing. It might or might not ever make >> sense to use a nonzero delay in VACUUM FULL, but the facility should be >> there. (Since plain and full VACUUM share the same index cleanup code, >> it would take some klugery to implement a policy of "no delays for >> VACUUM FULL" anyway.) >> >> 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? It gives regular backends more time to "retouch" the pages they actually need before they fall off the end of the LRU list. Jan -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #================================================== JanWieck@Yahoo.com #