Re: [HACKERS] [POC] Faster processing at Gather node
От | Rafia Sabih |
---|---|
Тема | Re: [HACKERS] [POC] Faster processing at Gather node |
Дата | |
Msg-id | CAOGQiiO7GEzWzRaeZWU3OsCeXZ6aOT=+riAWgv1jB8Sc9Tn1ZQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] [POC] Faster processing at Gather node (Andres Freund <andres@anarazel.de>) |
Список | pgsql-hackers |
On Thu, Nov 16, 2017 at 12:24 AM, Andres Freund <andres@anarazel.de> wrote: > Hi, > > On 2017-11-15 13:48:18 -0500, Robert Haas wrote: >> I think that we need a little bit deeper analysis here to draw any >> firm conclusions. > > Indeed. > > >> I suspect that one factor is that many of the queries actually send >> very few rows through the Gather. > > Yep. I kinda wonder if the same result would present if the benchmarks > were run with parallel_leader_participation. The theory being what were > seing is just that the leader doesn't accept any tuples, and the large > queue size just helps because workers can run for longer. > I ran Q12 with parallel_leader_participation = off and could not get any performance improvement with the patches given by Robert.The result was same for head as well. The query plan also remain unaffected with the value of this parameter. Here are the details of the experiment, TPC-H scale factor = 20, work_mem = 1GB random_page_cost = seq_page_cost = 0.1 max_parallel_workers_per_gather = 4 PG commit: 745948422c799c1b9f976ee30f21a7aac050e0f3 Please find the attached file for the explain analyse output for either values of parallel_leader_participation and patches. -- Regards, Rafia Sabih EnterpriseDB: http://www.enterprisedb.com/
Вложения
В списке pgsql-hackers по дате отправления: