[postgis-devel] Parallel Support
remi.cura at gmail.com
Sun Mar 27 14:21:49 PDT 2016
I've been watching the patch discussion on postgres list,
I must say this is a most wanted feature !
It is going to take Postgis to another level in terms of scalability.
Currently I use python for parallel query, and it is a major hassle.
PGadmin scripts are a little bit easier, but quit annoying as well.
2016-03-25 20:20 GMT+01:00 Paul Ramsey <pramsey at cleverelephant.ca>:
> FYI, I have a parallel query/aggregate branch going here
> I've marked most of the functions as PARALLEL SAFE, for better or worse.
> Aggregates are frustrating, the one that we probably want to
> parallelize the most, ST_Union, is quite tricky to do. Basically, we
> need to get parallelism into the transfn stage, since by the time you
> get to the combinefn or finalfn the result has already been returned
> to the master. In order to get some work done in the transfn I think
> we basically need to run a union every N records, which means a bad
> magic number in there, as well as washing out the benefits of cascaded
> You can still test a parallel union aggregate though, the ST_MemUnion
> aggregate is trivial to parallelize, and I have done so. Also
> ST_Extent. ST_Collect doesn't have any benefit to parallelizing (since
> it's mostly about memory copying).
> For testing you'll probably end up messing with the parallel gucs
> which are described here:
> postgis-devel mailing list
> postgis-devel at lists.osgeo.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the postgis-devel