Skip site navigation (1) Skip section navigation (2)

Re: Resumable vacuum proposal and design overview

From: "Simon Riggs" <simon(at)2ndquadrant(dot)com>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Matthew T(dot) O'Connor" <matthew(at)tocr(dot)com>,"Jim C(dot) Nasby" <jim(at)nasby(dot)net>,"Galy Lee" <lee(dot)galy(at)oss(dot)ntt(dot)co(dot)jp>,<pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Resumable vacuum proposal and design overview
Date: 2007-02-27 18:15:50
Message-ID: 1172600150.3760.775.camel@silverbirch.site (view raw or flat)
Thread:
Lists: pgsql-hackers
On Tue, 2007-02-27 at 12:23 -0500, Tom Lane wrote:
> "Matthew T. O'Connor" <matthew(at)tocr(dot)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



In response to

pgsql-hackers by date

Next:From: Gregory StarkDate: 2007-02-27 18:21:37
Subject: Re: bug in gist hstore?
Previous:From: Tom LaneDate: 2007-02-27 18:13:06
Subject: Re: Packed short varlenas, what next?

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group