| From: | David Rowley <david(dot)rowley(at)2ndquadrant(dot)com> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | Simon Riggs <simon(at)2ndquadrant(dot)com>, Thom Brown <thom(at)linux(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: max_parallel_degree context level |
| Date: | 2016-03-20 07:01:07 |
| Message-ID: | CAKJS1f-4Optkg+C9cghixYg2oSEb0Trp3HmxoQgjPnyzw7f-NA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 12 February 2016 at 04:55, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Thu, Feb 11, 2016 at 10:32 AM, Simon Riggs <simon(at)2ndquadrant(dot)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.
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Amit Kapila | 2016-03-20 07:01:58 | Re: Patch: fix lock contention for HASHHDR.mutex |
| Previous Message | Fabien COELHO | 2016-03-20 06:39:16 | Re: pgbench stats per script & other stuff |