Re: [HACKERS] modeling parallel contention (was: Parallel Append implementation) - Mailing list pgsql-hackers

From David Rowley
Subject Re: [HACKERS] modeling parallel contention (was: Parallel Append implementation)
Date
Msg-id CAKJS1f_A3bREii33+JzmEwR3wyBah6pYDdEZm6AeCZ_X_xk+Fg@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] modeling parallel contention (was: Parallel Appendimplementation)  (Andres Freund <andres@anarazel.de>)
Responses Re: [HACKERS] modeling parallel contention (was: Parallel Append implementation)  (Thomas Munro <thomas.munro@enterprisedb.com>)
List pgsql-hackers
On 5 May 2017 at 13:37, Andres Freund <andres@anarazel.de> wrote:
> On 2017-05-02 15:13:58 -0400, Robert Haas wrote:
>> Multiple people (including David Rowley
>> as well as folks here at EnterpriseDB) have demonstrated that for
>> certain queries, we can actually use a lot more workers and everything
>> works great.  The problem is that for other queries, using a lot of
>> workers works terribly.  The planner doesn't know how to figure out
>> which it'll be - and honestly, I don't either.
>
> Have those benchmarks, even in a very informal form, been shared /
> collected / referenced centrally?  I'd be very interested to know where
> the different contention points are. Possibilities:

I posted mine on [1], although the post does not go into much detail
about the contention points. I only really briefly mention it at the
end.

[1] https://blog.2ndquadrant.com/parallel-monster-benchmark/#comment-248273

-- David Rowley                   http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services



pgsql-hackers by date:

Previous
From: Haribabu Kommi
Date:
Subject: [HACKERS] compiler warning with VS 2017
Next
From: Andres Freund
Date:
Subject: Re: [HACKERS] modeling parallel contention (was: Parallel Appendimplementation)