Re: bg worker: patch 1 of 6 - permanent process

On 09/14/2010 08:06 PM, Robert Haas wrote:
> 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.

That's pretty close to how bgworkers are implemented, now. Except for 
the need to terminate after a certain period of time. What is that 
intended to be good for?

Especially considering that the avlauncher/coordinator knows the current 
amount of work (number of jobs) per database.

> 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.

Well, the pressure has simply been bigger for Postgres-R.

It should be possible to do benchmarks using Postgres-R and compare 
against a max_idle_background_workers = 0 configuration that leads to 
termination and re-connecting for ever remote transaction to be applied. 
However, that's not going to say anything about whether or not it's 
worth it for autovacuum.

Regards

Markus Wanner