Re: max_parallel_degree > 0 for 9.6 beta - Mailing list pgsql-hackers

From Robert Haas
Subject Re: max_parallel_degree > 0 for 9.6 beta
Date
Msg-id CA+TgmoaBxy-19dtZMxit-iWcQ2H1bXFOfO-sOdVDEg0JycGi2w@mail.gmail.com
Whole thread Raw
In response to Re: max_parallel_degree > 0 for 9.6 beta  ("Joshua D. Drake" <jd@commandprompt.com>)
List pgsql-hackers
On Fri, Apr 22, 2016 at 10:07 AM, Joshua D. Drake <jd@commandprompt.com> wrote:
> This is the problem right here.
>
> We should be shipping for a reasonable production configuration. It is not
> reasonable to assume that someone is going to be running on a Rasberry Pi 2.
> Yes, we can effectively run on that platform that doesn't mean it should be
> our default target configuration. Consider that a 5.00/mo Digital Ocean VM
> is going to outperform a Rasberry Pi.

I don't disagree with that, and I think there is a considerable amount
of work that could be done to create a saner "out of the box"
configuration.  But I don't think that the two weeks before beta is
the right time to start building a consensus around what that might
look like.

> True, but isn't that also what context switching and (possibly)
> hyperthreading are for?

Sure.  What you should expect, though, is that overall system
throughput will be higher if the system is not oversubscribed.  You
can use parallel query selectively to speed up certain queries even if
that takes you above the number of CPUs you have; if those queries are
on a deadline, finishing them sooner may be worth whatever you lose in
overall throughput.

> I think your argument sounds more like a production solution, not a Beta
> solution. We should be pushing it a little bit in Beta.

Shipping with max_parallel_workers=2 *is* pushing it a little bit.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: VS 2015 support in src/tools/msvc
Next
From: Stephen Frost
Date:
Subject: Re: pg_dump dump catalog ACLs