On Sun, Mar 20, 2016 at 3:01 AM, David Rowley <david.row...@2ndquadrant.com> wrote: > On 12 February 2016 at 04:55, Robert Haas <robertmh...@gmail.com> wrote: >> On Thu, Feb 11, 2016 at 10:32 AM, Simon Riggs <si...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
