On 15/03/2016 21:12, Robert Haas wrote: > On Mon, Mar 14, 2016 at 9:25 PM, David Rowley > <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.
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.
