On Tue, Jun 14, 2016 at 7:10 AM, Julien Rouhaud <julien.rouh...@dalibo.com> wrote: >> I don't entirely like the new logic in >> RegisterDynamicBackgroundWorker. > > I'm not that happy with it too. We can avoid iterating over every slots > if the feature isn't activated though (max_parallel_workers >= > max_worker_processes). > >> I wonder if we can't drive this off >> of a couple of counters, instead of having the process registering the >> background worker iterate over every slot. Suppose we add two >> counters to BackgroundWorkerArray, parallel_register_count and >> parallel_terminate_count. Whenever a backend successfully registers a >> parallel worker, it increments parallel_register_count. Whenever the >> postmaster marks a parallel wokrer slot as no longer in use, it >> increments parallel_terminate_count. Then, the number of active >> parallel workers is just parallel_register_count - >> parallel_terminate_count. (We can't have the postmaster and the >> backends share the same counter, because then it would need locking, >> and the postmaster can't try to take spinlocks - can't even use >> atomics, because those might be emulated using spinlocks.) >> > > I wanted to maintain counters at first, but it seemed more invasive, and > I thought that the max_parallel_worker would be ueful in environnements > where there're lots of parallel workers and dynamic workers used, so > finding a free slot would require iterating over most of the slots most > of the time anyway. I'm of course also ok with maintaining counters.
I think we should go that way. Some day we might try to make the process of finding a free slot more efficient than it is today; I'd rather not double down on linear search. Are you going to update this patch? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
