On 06/02/2016 01:08 PM, David G. Johnston wrote:
> On Thu, Jun 2, 2016 at 3:52 PM, Josh berkus <j...@agliodbs.com
> <mailto:j...@agliodbs.com>>wrote:
> 
>     On 06/02/2016 08:53 AM, Tom Lane wrote:
>     > Josh berkus <j...@agliodbs.com <mailto:j...@agliodbs.com>> writes:
>     >> On 06/02/2016 04:58 AM, Robert Haas wrote:
>     >>> Well, I think we could drop node, if you like.  I think parallel
>     >>> wouldn't be good to drop, though, because it sounds like we want a
>     >>> global limit on parallel workers also, and that can't be just
>     >>> max_workers.  So I think we should keep parallel in there for all of
>     >>> them, and have max_parallel_workers and
>     >>> max_parallel_workers_per_gather(_node).  The reloption and the Path
>     >>> struct field can be parallel_workers rather than parallel_degree.
>     >
>     >> So does that mean we'll rename it if you manage to implement a 
> parameter
>     >> which controls the number of workers for the whole statement?
>     >
>     > That would fit in as something like max_parallel_workers_per_statement.
> 
>     ETOOMANYKNOBS
> 
>     I'm trying to think of some way we can reasonably automate this for
>     users ...
> 
> 
> ​Are you referring to right now or if we move the goal posts to making
> this a per-statement reservation?​

I was assuming that we would have *both* per-operation and per-statement
limits.  I can see reasons for having both, I can see why power users
would want both, but it's going to be overwhelming to casual users.


-- 
--
Josh Berkus
Red Hat OSAS
(any opinions are my own)


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Reply via email to