Re: Choosing parallel_degree - Mailing list pgsql-hackers

<div dir="ltr">On Tue, Mar 15, 2016 at 8:26 PM, Julien Rouhaud <span dir="ltr"><<a
href="mailto:julien.rouhaud@dalibo.com"target="_blank">julien.rouhaud@dalibo.com</a>></span> wrote:<br /><div
class="gmail_extra"><divclass="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px
#cccsolid;padding-left:1ex"><span class="">On 15/03/2016 21:12, Robert Haas wrote:<br /> > On Mon, Mar 14, 2016 at
9:25PM, David Rowley<br /> > <<a href="mailto:david.rowley@2ndquadrant.com">david.rowley@2ndquadrant.com</a>>
wrote:<br/> >> Over in [1] James mentioned about wanting more to be able to have more<br /> >> influence
overthe partial path's parallel_degree decision.  At risk<br /> >> of a discussion on that hijacking the parallel
aggregatethread, I<br /> >> thought I'd start this for anyone who would want to discuss making<br /> >>
changesto that.<br /> >><br /> >> I've attached a simple C program which shows the parallel_degree which<br
/>>> will be chosen at the moment. For now it's based on the size of the<br /> >> base relation. Perhaps
thatwill need to be rethought later, perhaps<br /> >> based on costs. But I just don't think it's something for
9.6.<br/> ><br /> > I thought about this a bit more.  There are a couple of easy things we<br /> > could do
here.<br/> ><br /> > The 1000-page threshold could be made into a GUC.<br /> ><br /> > We could add a
per-tablereloption for parallel-degree that would<br /> > override the calculation.<br /> ><br /> > Neither of
thosethings is very smart, but they'd probably both help<br /> > some people.  If someone is able to produce a patch
foreither or both<br /> > of these things *quickly*, we could possibly try to squeeze it into<br /> > 9.6 as a
cleanupof work already done.<br /> ><br /><br /></span>I'm not too familiar with parallel planning, but I tried to
implement<br/> both in attached patch. I didn't put much effort into the<br /> parallel_threshold GUC documentation,
becauseI didn't really see a good<br /> way to explain it. I'd e happy to improve it if needed. Also, to make<br />
thisparameter easier to tune for users, perhaps we could divide the<br /> default value by 3 and use it as is in the
firstiteration in<br /> create_parallel_path() <span class="HOEnZb"><font color="#888888"><br
/></font></span></blockquote></div><br/></div><div class="gmail_extra">Hmm.  I'm not sure I like the parallel_threshold
GUCafter all.  That's a little strange.  But maybe.<br /><br /></div><div class="gmail_extra">For the reloption, I was
thinkingit would be parallel_degree, not max_parallel_degree.  max_parallel_degree would still control, so if the
parallel_degreefor a given table was greater than max_parallel_degree, you'd get max_parallel_degree instead.  But you
couldcrank up the parallel_degree for a small table to force more parallelism when querying it.<br clear="all"
/></div><divclass="gmail_extra"><br />-- <br /><div class="gmail_signature">Robert Haas<br />EnterpriseDB: <a
href="http://www.enterprisedb.com"target="_blank">http://www.enterprisedb.com</a><br />The Enterprise PostgreSQL
Company</div></div></div>