On 14/06/2016 04:09, Robert Haas wrote: > On Mon, Jun 13, 2016 at 5:42 AM, Julien Rouhaud > <julien.rouh...@dalibo.com> wrote: >> Agreed, and fixed in attached v3. > > 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. > If we want to allow the number of parallel workers started to be available > for statistical purposes, we can keep to uint32 values for that > (parallel_register_count_lo and parallel_register_count_hi, for > example), and increment the second one whenever the first one rolls > over to zero. > I didn't think about monitoring. I'm not sure if this counter would be really helpful without also having the number of time a parallel worker couldn't be launched (and I'd really like to have this one). -- Julien Rouhaud http://dalibo.com - http://dalibo.org -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
