From: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "Matthew T(dot) O'Connor" <matthew(at)zeut(dot)net>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Experimental patch for inter-page delay in VACUUM |
Date: | 2003-10-31 16:42:20 |
Message-ID: | 200310311642.h9VGgKW29891@candle.pha.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane wrote:
> "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.
What is the advantage of delaying vacuum per page vs. just doing vacuum
less frequently?
--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
From | Date | Subject | |
---|---|---|---|
Next Message | Jan Wieck | 2003-10-31 17:02:27 | Re: 7.4RC1 planned for Monday |
Previous Message | Peter Eisentraut | 2003-10-31 16:37:10 | Re: Call for port reports |