Re: Vacuum Daemon - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Vacuum Daemon
Date
Msg-id 16397.1025396092@sss.pgh.pa.us
Whole thread Raw
In response to Vacuum Daemon  ("Matthew T. O'Connor" <matthew@zeut.net>)
Responses Re: Vacuum Daemon
Re: Vacuum Daemon
List pgsql-hackers
"Matthew T. O'Connor" <matthew@zeut.net> writes:
> As of 7.2 we have lazy vacuum.  The next logical step is setting up vacuum to
> run automatically in the background either as some type of daemon or as 
> something kicked off by the postmaster.

> I am interested in working on this to do item, although I see it is assigned 
> to Tom right now.  

It's sufficiently far down my to-do list that I'm happy to let someone
else do it ;-).

> Second: There was some discussion 
> (http://archives.postgresql.org/pgsql-hackers/2002-05/msg00970.php) about 
> this not being neede once UNDO is on place, what is the current view on this?

I do not think that is the case; and anyway we've pretty much rejected
Vadim's notion of going to an Oracle-style UNDO buffer.  I don't foresee
VACUUM going away anytime soon --- what we need is to make it less
obtrusive.  7.2 made some progress in that direction, but we need more.

Launching VACUUMs on some automatic schedule, preferably using feedback
about where space needs to be reclaimed, seems like a pretty
straightforward small-matter-of-programming.  The thing that would
really be needed to make it unobtrusive is to find a way to run the
vacuum processing at low priority, or at least when the system is not
heavily loaded.  I don't know a good way to do that.  Nice'ing the
vacuum process won't work because of priority-inversion problems.
Making it suspend itself when load gets high might do; but how to
detect that in a reasonably portable fashion?
        regards, tom lane




pgsql-hackers by date:

Previous
From: "Matthew T. O'Connor"
Date:
Subject: Vacuum Daemon
Next
From: "J. R. Nield"
Date:
Subject: Re: Vacuum Daemon