On 2017-05-02 15:13:58 -0400, Robert Haas wrote: > On Tue, Apr 18, 2017 at 2:48 AM, Amit Khandekar <amitdkhan...@gmail.com> > wrote: > The main things that keeps this from being a crippling issue right now > is the fact that we tend not to use that many parallel workers in the > first place. We're trying to scale a query that would otherwise use 1 > process out to 3 or 5 processes, and so the contention effects, in > many cases, are not too bad. 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: - in non-resident workloads: too much concurrent IOs submitted, leading to overly much random IO - internal contention in the the parallel node, e.g. parallel seqscan - contention on PG componenents like buffer mapping, procarray, clog - contention on individual buffers, e.g. btree root pages, or small tables in nestloop joins - just too many context switches, due to ineffective parallelization probably multiple of those are a problem, but without trying to figure them out, we're going to have a hard time to develop a better costing model... Greetings, Andres Freund -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
