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
