From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Matthew T(dot) O'Connor" <matthew(at)zeut(dot)net> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Experimental patch for inter-page delay in VACUUM |
Date: | 2003-10-31 05:53:14 |
Message-ID: | 7473.1067579594@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"Matthew T. O'Connor" <matthew(at)zeut(dot)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.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Joe Conway | 2003-10-31 05:54:10 | Re: Annotated release notes |
Previous Message | Tom Lane | 2003-10-31 05:43:48 | Re: Annotated release notes |