Re: [HACKERS] modeling parallel contention (was: Parallel Append implementation)
От | David Rowley |
---|---|
Тема | Re: [HACKERS] modeling parallel contention (was: Parallel Append implementation) |
Дата | |
Msg-id | CAKJS1f_A3bREii33+JzmEwR3wyBah6pYDdEZm6AeCZ_X_xk+Fg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] modeling parallel contention (was: Parallel Appendimplementation) (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: [HACKERS] modeling parallel contention (was: Parallel Append implementation)
|
Список | 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 по дате отправления: