<div dir="ltr">Not marking something as PARALLEL SAFE just plainly disables parallel for everything in the query, this was the main reason for PARALLEL SAFE. Without Paul's modification you can still get benefit from parallelism, in form of say <div><br></div><div>SELECT class, ST_Union(ST_Buffer(geom, 1)) from sometable group by class;</div><div><br></div><div>- where a Buffer will be calculated in parallel, but Union will be performed for all the table in main worker afterwards.</div><div><br>Here's schematic of parallel aggregate:<br> <img src="cid:162200c96f0cb971f161" alt="image.png" class="" style="max-width: 100%; opacity: 1;"><br> - you must have sfunc in any aggregate :)<br> - if your transfer type does not match your output type, you make a finalfunc;<div> - if you define a combinefunc, Postgres starts having an option to run several workers - without it it has no idea how to combine two outputs from different workers;</div><div> - serialfunc/deserialfunc default to in/out functions of datatype.</div><div><br></div><div>Schematically serialfunc in each worker looks almost like finalfunc, just that it outputs not to user but to other worker. </div><div><br></div><div>Work is distributed just by giving relation page ranges to each worker. They don't pass parts of their work to one another.</div><div><br></div><div>Each thing in this machinery has its cost, so you'd want it to start only when you're sure it will get you results faster than usually. That's exactly the reason why it's so hard to make parallelism kick in on small tables, and why it shows not that good results on these :) </div><div><div><br></div><div>Whole part in the main worker becomes almost noop if all the rows for a GROUP BY key get into only one worker's part of relation. Combinefunc is then not called, and finalfunc skips GEOS call as it's got just one element in array.</div><div><br></div><div><br><div class="gmail_quote"><div dir="ltr">вт, 13 мар. 2018 г. в 18:15, Regina Obe <<a href="mailto:lr@pcorp.us">lr@pcorp.us</a>>:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple"><div class="m_6982668388641209100WordSection1"><div><div><p class="MsoNormal" style="margin-left:.5in"><u></u> <u></u></p></div><div><p class="MsoNormal" style="margin-left:.5in"><span style="color:#1f497d">>  </span>I think the benchmark you do here does not cover a common case of big table grouped by some attributive column. If the dataset is reasonably clustered, and <span style="color:#1f497d"><u></u><u></u></span></p><p class="MsoNormal" style="margin-left:.5in"><span style="color:#1f497d">> </span>number of threads is smaller than number of groups, one can expect a Parallel Seq Scan to bring all the rows for one group most of the time, so that Cascaded <span style="color:#1f497d"><u></u><u></u></span></p><p class="MsoNormal" style="margin-left:.5in"><span style="color:#1f497d">> </span>Union is performed in parallel worker and then main worker is just passing the result upwards. Costs adjustments can be tricky for that though.<u></u><u></u></p></div></div></div></div><div lang="EN-US" link="blue" vlink="purple"><div class="m_6982668388641209100WordSection1"><div><div><p class="MsoNormal" style="margin-left:.5in"><span style="color:#1f497d"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">I may have misunderstood how this works, but in the case you describe I thought the ST_Union would happen after data is partitoned to each worker node so the union step wouldn't be parallelized but would occur in each worker so would run in parallel for each set of groups.<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">Since ST_Union is marked as safe, wouldn't it be already taking advantage of this?<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">To be honest I've never tested this out but that was the main impetus for marking ST_Union parallel safe to allow the ST_Union to still happen in a worker node.<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">Thanks,<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">Regina<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u> <u></u></span></p></div></div></div></div>_______________________________________________<br>
postgis-devel mailing list<br>
<a href="mailto:postgis-devel@lists.osgeo.org" target="_blank">postgis-devel@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/postgis-devel" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/postgis-devel</a></blockquote></div></div></div></div></div>