On 09/14/2010 08:41 PM, Robert Haas wrote:
To avoid consuming system resources forever if they're not being used.
Well, what timeout would you choose. And how would you justify it compared to the amounts of system resources consumed by an idle process sitting there and waiting for a job?
I'm not against such a timeout, but so far I felt that unlimited would be the best default.
Well, presumably that would be fairly disastrous. I would think, though, that you would not have a min/max number of workers PER DATABASE, but an overall limit on the upper size of the total pool
That already exists (in addition to the other parameters).
- I can't see any reason to limit the minimum size of the pool, but I might be missing something.
I tried to mimic what others do, for example apache pre-fork. Maybe it's just another way of trying to keep the overall resource consumption at a reasonable level.
The minimum is helpful to eliminate waits for backends starting up. Note here that the coordinator can only request to fork one new bgworker at a time. It then needs to wait until that new bgworker registers with the coordinator, until it can request further bgworkers from the postmaster. (That's due to the limitation in communication between the postmaster and coordinator).
Personally, my position is that if someone does something that is only a small improvement on its own but which has the potential to help with other things later, that's a perfectly legitimate patch and we should try to accept it. But if it's not a clear (even if small) win then the bar is a lot higher, at least in my book.
I don't think it's an improvement over the current autovacuum behavior. Not intended to be one. But it certainly shouldn't hurt, either.
It only has the potential to help with other things, namely parallel querying. And of course replication (Postgres-R). Or any other kind of background job you come up with (where background means not requiring a client connection).
Regards Markus Wanner -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
