Re: Rename max_parallel_degree?
Julien Rouhaud <julien.rouhaud@dalibo.com>
From: Julien Rouhaud <julien.rouhaud@dalibo.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Josh Berkus <josh@agliodbs.com>,
"David G. Johnston" <david.g.johnston@gmail.com>,
Amit Kapila <amit.kapila16@gmail.com>, Peter Geoghegan <pg@heroku.com>,
Noah Misch <noah@leadboat.com>, David Rowley <david.rowley@2ndquadrant.com>,
Alvaro Herrera <alvherre@2ndquadrant.com>,
Magnus Hagander <magnus@hagander.net>, Bruce Momjian <bruce@momjian.us>,
PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2016-06-14T11:10:01Z
Lists: pgsql-hackers
On 14/06/2016 04:09, Robert Haas wrote: > On Mon, Jun 13, 2016 at 5:42 AM, Julien Rouhaud > <julien.rouhaud@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