<div dir="ltr"><div class="gmail_default" style="font-family:monospace,monospace">I've been watching the patch discussion on postgres list, <br></div><div class="gmail_default" style="font-family:monospace,monospace">I must say this is a most wanted feature ! <br></div><div class="gmail_default" style="font-family:monospace,monospace">It is going to take Postgis to another level in terms of scalability.<br></div><div class="gmail_default" style="font-family:monospace,monospace"><br>Currently I use python for parallel query, and it is a major hassle. <br></div><div class="gmail_default" style="font-family:monospace,monospace">PGadmin scripts are a little bit easier, but quit annoying as well.<br></div><div class="gmail_default" style="font-family:monospace,monospace"><br>Cheers,<br></div><div class="gmail_default" style="font-family:monospace,monospace">Rémi-C<br></div></div><div class="gmail_extra"><br><div class="gmail_quote">2016-03-25 20:20 GMT+01:00 Paul Ramsey <span dir="ltr"><<a href="mailto:pramsey@cleverelephant.ca" target="_blank">pramsey@cleverelephant.ca</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">FYI, I have a parallel query/aggregate branch going here<br>
<br>
<a href="https://github.com/pramsey/postgis/tree/parallel" rel="noreferrer" target="_blank">https://github.com/pramsey/postgis/tree/parallel</a><br>
<br>
I've marked most of the functions as PARALLEL SAFE, for better or worse.<br>
<br>
Aggregates are frustrating, the one that we probably want to<br>
parallelize the most, ST_Union, is quite tricky to do. Basically, we<br>
need to get parallelism into the transfn stage, since by the time you<br>
get to the combinefn or finalfn the result has already been returned<br>
to the master. In order to get some work done in the transfn I think<br>
we basically need to run a union every N records, which means a bad<br>
magic number in there, as well as washing out the benefits of cascaded<br>
union.<br>
<br>
You can still test a parallel union aggregate though, the ST_MemUnion<br>
aggregate is trivial to parallelize, and I have done so. Also<br>
ST_Extent. ST_Collect doesn't have any benefit to parallelizing (since<br>
it's mostly about memory copying).<br>
<br>
For testing you'll probably end up messing with the parallel gucs<br>
which are described here:<br>
<br>
<a href="https://gist.github.com/pramsey/ff7cbf70dbe581189565" rel="noreferrer" target="_blank">https://gist.github.com/pramsey/ff7cbf70dbe581189565</a><br>
<br>
P.<br>
_______________________________________________<br>
postgis-devel mailing list<br>
<a href="mailto:postgis-devel@lists.osgeo.org">postgis-devel@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/postgis-devel" rel="noreferrer" target="_blank">http://lists.osgeo.org/mailman/listinfo/postgis-devel</a></blockquote></div><br></div>