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: http://www.postgresql.org/mailpref/pgsql-hackers
