Robert, On 09/20/2010 06:57 PM, Robert Haas wrote: > Gee, that doesn't seem slow enough to worry about to me. If we > suppose that you need 2 * CPUs + spindles processes to fully load the > system, that means you should be able to ramp up from zero to > consuming every available system resource in under a second; except > perhaps on a system with a huge RAID array, which might need 2 or 3 > seconds. If you parallelize the worker startup, as you suggest, I'd > think you could knock quite a bit more off of this, but why all the > worry about startup latency? Once the system is chugging along, none > of this should matter very much, I would think. If you need to > repeatedly kill off some workers bound to one database and start some > new ones to bind to a different database, that could be sorta painful, > but if you can actually afford to keep around the workers for all the > databases you care about, it seems fine.
Hm.. I see. So in other words, you are saying min_spare_background_workers isn't flexible enough in case one has thousands of databases but only uses a few of them frequently. I understand that reasoning and the wish to keep the number of GUCs as low as possible. I'll try to drop the min_spare_background_workers from the bgworker patches. The rest of the bgworker infrastructure should behave pretty much like what you have described. Parallelism in starting bgworkers could be a nice improvement, especially if we kill the min_space_background_workers mechanism. > Neat stuff. Thanks. 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