From: | Julien Rouhaud <julien(dot)rouhaud(at)dalibo(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Josh Berkus <josh(at)agliodbs(dot)com>, "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Peter Geoghegan <pg(at)heroku(dot)com>, Noah Misch <noah(at)leadboat(dot)com>, David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Magnus Hagander <magnus(at)hagander(dot)net>, Bruce Momjian <bruce(at)momjian(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Rename max_parallel_degree? |
Date: | 2016-06-14 11:10:01 |
Message-ID: | f5aadd54-6ea0-c8a2-a414-612acdbdab46@dalibo.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 14/06/2016 04:09, Robert Haas wrote:
> On Mon, Jun 13, 2016 at 5:42 AM, Julien Rouhaud
> <julien(dot)rouhaud(at)dalibo(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Kapila | 2016-06-14 11:18:33 | Re: ERROR: ORDER/GROUP BY expression not found in targetlist |
Previous Message | Andreas Karlsson | 2016-06-14 10:44:17 | Use of CREATE OR REPLACE in bloom--1.0.sql |