Re: Choosing parallel_degree - Mailing list pgsql-hackers

From Julien Rouhaud
Subject Re: Choosing parallel_degree
Date
Msg-id 56E98E2D.8040005@dalibo.com
Whole thread Raw
In response to Re: Choosing parallel_degree  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Choosing parallel_degree
List pgsql-hackers
On 16/03/2016 17:16, Robert Haas wrote:
> On Tue, Mar 15, 2016 at 8:26 PM, Julien Rouhaud
> <julien.rouhaud@dalibo.com <mailto:julien.rouhaud@dalibo.com>> wrote:
> 
>     On 15/03/2016 21:12, Robert Haas wrote:
>     > On Mon, Mar 14, 2016 at 9:25 PM, David Rowley
>     > <david.rowley@2ndquadrant.com <mailto:david.rowley@2ndquadrant.com>>
>     wrote:
>     >> Over in [1] James mentioned about wanting more to be able to have more
>     >> influence over the partial path's parallel_degree decision.  At risk
>     >> of a discussion on that hijacking the parallel aggregate thread, I
>     >> thought I'd start this for anyone who would want to discuss making
>     >> changes to that.
>     >>
>     >> I've attached a simple C program which shows the parallel_degree which
>     >> will be chosen at the moment. For now it's based on the size of the
>     >> base relation. Perhaps that will need to be rethought later, perhaps
>     >> based on costs. But I just don't think it's something for 9.6.
>     >
>     > I thought about this a bit more.  There are a couple of easy things we
>     > could do here.
>     >
>     > The 1000-page threshold could be made into a GUC.
>     >
>     > We could add a per-table reloption for parallel-degree that would
>     > override the calculation.
>     >
>     > Neither of those things is very smart, but they'd probably both help
>     > some people.  If someone is able to produce a patch for either or both
>     > of these things *quickly*, we could possibly try to squeeze it into
>     > 9.6 as a cleanup of work already done.
>     >
> 
>     I'm not too familiar with parallel planning, but I tried to implement
>     both in attached patch. I didn't put much effort into the
>     parallel_threshold GUC documentation, because I didn't really see a good
>     way to explain it. I'd e happy to improve it if needed. Also, to make
>     this parameter easier to tune for users, perhaps we could divide the
>     default value by 3 and use it as is in the first iteration in
>     create_parallel_path()
> 
> 
> Hmm.  I'm not sure I like the parallel_threshold GUC after all.  That's
> a little strange.  But maybe.
> 

FWIW I have two commits in my local branch, so I can remove this one easily.

> For the reloption, I was thinking it would be parallel_degree, not
> max_parallel_degree.  max_parallel_degree would still control, so if the
> parallel_degree for a given table was greater than max_parallel_degree,
> you'd get max_parallel_degree instead.  But you could crank up the
> parallel_degree for a small table to force more parallelism when
> querying it.
> 

Something like a "min_parallel_degree" then ?


-- 
Julien Rouhaud
http://dalibo.com - http://dalibo.org



pgsql-hackers by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: plpgsql - DECLARE - cannot to use %TYPE or %ROWTYPE for composite types
Next
From: Tom Lane
Date:
Subject: Re: Re: [COMMITTERS] pgsql: Only try to push down foreign joins if the user mapping OIDs mat