Re: [HACKERS] [POC] Faster processing at Gather node

From: Rafia Sabih <rafia(dot)sabih(at)enterprisedb(dot)com>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, PostgreSQL Developers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [HACKERS] [POC] Faster processing at Gather node
Date: 2017-11-23 10:12:54
Views: Raw Message | Whole Thread | Download mbox
Lists: pgsql-hackers

On Thu, Nov 16, 2017 at 12:24 AM, Andres Freund <andres(at)anarazel(dot)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.
Rafia Sabih

Attachment Content-Type Size
plp_patch.txt text/plain 3.7 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Rui Hai Jiang 2017-11-23 10:38:59 How is the PostgreSQL debuginfo file generated
Previous Message Ildus Kurbangaliev 2017-11-23 09:38:49 Re: [HACKERS] Custom compression methods