Re: Experimental patch for inter-page delay in VACUUM
От | Jan Wieck |
---|---|
Тема | Re: Experimental patch for inter-page delay in VACUUM |
Дата | |
Msg-id | 3FA29A6A.2000108@Yahoo.com обсуждение исходный текст |
Ответ на | Re: Experimental patch for inter-page delay in VACUUM (Bruce Momjian <pgman@candle.pha.pa.us>) |
Список | 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 #
В списке pgsql-hackers по дате отправления: