Re: Resumable vacuum proposal and design overview - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: Resumable vacuum proposal and design overview
Date
Msg-id 1172600150.3760.775.camel@silverbirch.site
Whole thread Raw
In response to Re: Resumable vacuum proposal and design overview  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Tue, 2007-02-27 at 12:23 -0500, Tom Lane wrote:
> "Matthew T. O'Connor" <matthew@tocr.com> writes:
> > Tom Lane wrote:
> >> It occurs to me that we may be thinking about this the wrong way
> >> entirely.  Perhaps a more useful answer to the problem of using a
> >> defined maintenance window is to allow VACUUM to respond to changes in
> >> the vacuum cost delay settings on-the-fly.  So when your window closes,
> >> you don't abandon your work so far, you just throttle your I/O rate back
> >> to whatever's considered acceptable for daytime vacuuming.
> 
> > I thought we already did that?
> 
> No, we only react to SIGHUP when idle.  I think that's a good policy for
> standard backends, but for autovacuum it might be appropriate to check
> more often.

You mean react to changes while in the middle of a VACUUM? Sounds like a
great idea to me.

Not sure why you'd do that just for autovacuum though. Sounds like it
would be good in all cases. Vacuum and autovacuum have different vacuum
delays, after all.

--  Simon Riggs              EnterpriseDB   http://www.enterprisedb.com




pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Packed short varlenas, what next?
Next
From: Gregory Stark
Date:
Subject: Re: bug in gist hstore?