On 16/03/2016 17:16, Robert Haas wrote:
> On Tue, Mar 15, 2016 at 8:26 PM, Julien Rouhaud
> <julien.rouh...@dalibo.com <mailto:julien.rouh...@dalibo.com>> wrote:
>     On 15/03/2016 21:12, Robert Haas wrote:
>     > On Mon, Mar 14, 2016 at 9:25 PM, David Rowley
>     > <david.row...@2ndquadrant.com <mailto:david.row...@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

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to