[postgis-devel] Parallel Support

[Paul Ramsey]

PostgreSQL specifically doesn't do threading, it fires up background
workers on the fly.
The main thing we get from PostgreSQL is functionality "for free".
Free sequence parallel, free join parallel, etc.
If we start threading we bang up against platform differences a little
harder than usual. I have a threading mode in the kmeans clustering,
but it's pthreads, which makes windows compilation problematic. We
could pull in an abstraction layer *as well*, but then... also the
question of how many threads to use is a bit open, though I guess now
we could just lean on the max_parallel_workers GUC to get the base
database configuration info for that.
Basically we haven't done threads on our side for historical reasons
of portability and complexity. Times have changed though, so maybe
it's a safer bet now.

P.


On Tue, Mar 29, 2016 at 9:44 AM, Sandro Santilli <strk at keybit.net> wrote:
> On Tue, Mar 29, 2016 at 08:46:20AM -0700, Paul Ramsey wrote:
>
>> The best suggestion so far has been from Staphen Frost, to allow the
>> workers to run their own "finalfn" or a "worker-side combine" as I
>> call it, so that we can cascade the sets first at the worker level,
>> then run one final combine on master before returning.
>
> How about handling threads directly from within postgis
> or in the CascadedUnion case directly from within libgeos ?
>
> What do PostgreSQL threads add to custom threads ?
>
> --strk;
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/postgis-devel