Tom Lane wrote:"Matthew T. O'Connor" <[EMAIL PROTECTED]> 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. # #================================================== [EMAIL PROTECTED] #
---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster
