On Sun, Mar 20, 2016 at 3:01 AM, David Rowley
<david.rowley@2ndquadrant.com> wrote:
> On 12 February 2016 at 04:55, Robert Haas <robertmhaas@gmail.com> wrote:
>> On Thu, Feb 11, 2016 at 10:32 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
>>> Is it slower if you request N workers, yet only 1 is available?
>>
>> I sure hope so. There may be some cases where more workers are slower
>> than fewer workers, but those cases are defects that we should try to
>> fix.
>
> It would only take anything but the CPU to be a bottleneck for this to
> be highly likely the case.
> If a non-parallel query is bound on I/O, then adding workers is most
> likely going to slow it down further. I've seen this when testing
> parallel aggregates.
Yeah. If you're bottlenecked on I/O, having more workers fighting
over the limited amount of CPU work available just adds context
switching and communication overhead. That's not a particularly easy
problem to solve. One can imagine a system where the workers exit if
they turn out not be needed, but then of course you might end up
needing them later if the situation shifts. I think eventually we
should have the ability for workers to both dynamically leave queries
that are I/O bound and dynamically join queries that become CPU bound,
but that is going to be a bit more than we can fit into 9.6.
Meanwhile, I made the change that was the original purpose of this thread.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company