Re: max_parallel_degree > 0 for 9.6 beta

On 04/22/2016 06:47 AM, Robert Haas wrote:
> On Fri, Apr 22, 2016 at 9:33 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>>> On Thu, Apr 21, 2016 at 7:20 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>>> Is that because max_worker_processes is only 8 by default? Maybe we
>>>> need to raise that, at least for beta purposes?
>>
>>> I'm not really in favor of that. I mean, almost all of our default
>>> settings are optimized for running PostgreSQL on, for example, a
>>> Raspberry Pi 2, so it would seem odd to suddenly swing the other
>>> direction and assume that there are more than 8 unused CPU cores.

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.

>
> It is much less likely to be true for parallel workers. The reason
> why those processes aren't contending for the CPU at the same time is
> generally that most of the connections are in fact idle. But a
> parallel worker is never idle. It is launched when it is needed to
> run a query and exits immediately afterward. If it's not contending
> for the CPU, it will be contending for I/O bandwidth, or a lock.
>

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

>> So what I'm concerned about for beta purposes is that we have a setup that
>> can exercise cases like, say, varying orders in which different workers
>> return tuples, or potential deadlocks between sibling workers. We'd get
>> no coverage of that behavioral space at max_parallel_degree=1. I'm not
>> really convinced that we'll get adequate coverage at
>> max_parallel_degree=2.
>
> The right solution to that is for people who have the right hardware
> to raise the settings, not to unleash a ridiculous set of defaults on
> everyone. I really hope that some people do serious destruction
> testing of parallel query and try to break it. For example, you could
> use the parallel_degree reloption to force 100 parallel workers to
> scan the same relation. That's likely to be dog slow, but it might
> well turn up some bugs.

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

JD

>

--
Command Prompt, Inc. http://the.postgres.company/
+1-503-667-4564
PostgreSQL Centered full stack support, consulting and development.
Everyone appreciates your honesty, until you are honest with them.