On Tue, Sep 14, 2010 at 1:56 PM, Alvaro Herrera
<alvherre@commandprompt.com> wrote:
> Excerpts from Tom Lane's message of mar sep 14 13:46:17 -0400 2010:
>> Alvaro Herrera <alvherre@commandprompt.com> writes:
>> > I think we've had enough problems with the current design of forking a
>> > new autovac process every once in a while, that I'd like to have them as
>> > permanent processes instead, waiting for orders from the autovac
>> > launcher. From that POV, bgworkers would make sense.
>>
>> That seems like a fairly large can of worms to open: we have never tried
>> to make backends switch from one database to another, and I don't think
>> I'd want to start such a project with autovac.
>
> Yeah, what I was thinking is that each worker would still die after
> completing the run, but a new one would be started immediately; it would
> go to sleep until a new assignment arrived. (What got me into this was
> the whole latch thing, actually.)
>
> This is a very raw idea however, so don't mind me much.
What would be the advantage of that?
One idea I had was to have autovacuum workers stick around for a
period of time after finishing their work. When we need to autovacuum
a database, first check whether there's an existing worker that we can
use, and if so use him. If not, start a new one. If that puts us
over the max number of workers, kill of the one that's been waiting
the longest. But workers will exit anyway if not reused after a
certain period of time.
The idea here would be to try to avoid all the backend startup costs:
process creation, priming the caches, etc. But I'm not really sure
it's worth the effort. I think we need to look for ways to further
reduce the overhead of vacuuming, but this doesn't necessarily seem
like the thing that would have the most bang for the buck.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company