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 #