Re: [DESIGN] ParallelAppend - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: [DESIGN] ParallelAppend
Date
Msg-id CAA4eK1+Ak_dpixiGK+zJ_DQ9X9nv9bHDRupotsMGWzpH9-L_oA@mail.gmail.com
Whole thread Raw
In response to Re: [DESIGN] ParallelAppend  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: [DESIGN] ParallelAppend  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On Fri, Nov 20, 2015 at 7:06 PM, Robert Haas <robertmhaas@gmail.com> wrote:
>
> On Fri, Nov 20, 2015 at 12:45 AM, Amit Kapila <amit.kapila16@gmail.com> wrote:
> > Okay, but I think that's not what I am talking about.  I am talking about
> > below code in cost_seqscan:
> >
> > - if (nworkers > 0)
> >
> > - run_cost = run_cost / (nworkers + 0.5);
> >
> > + if (path->parallel_degree > 0)
> >
> > + run_cost = run_cost / (path->parallel_degree + 0.5);
> >
> >
> > It will consider 50% of master backends effort for scan of each child
> > relation,
> > does that look correct to you?  Wouldn't 50% of master backends effort be
> > considered to scan all the child relations?
>
> In the code you originally wrote, you were adding 1 there rather than
> 0.5.  That meant you were expecting the leader to do as much work as
> each of its workers, which is clearly a bad estimate, because the
> leader also has to do the work of gathering tuples from the workers.
> 0.5 might not be the right value, but it's surely better than 1.
>
 
Without this patch, that 0.5 (or 50% of leaders effort) is considered for
Gather node irrespective of the number of workers or other factors, but
I think with Patch that is no longer true and that's what I am worrying
about.


With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com

pgsql-hackers by date:

Previous
From: Greg Stark
Date:
Subject: Re: onlyvalue aggregate (was: First Aggregate Funtion?)
Next
From: Peter Eisentraut
Date:
Subject: Re: documentation for wal_retrieve_retry_interval