From: | Paul Ramsey <pramsey(at)cleverelephant(dot)ca> |
---|---|
To: | Stephen Frost <sfrost(at)snowman(dot)net> |
Cc: | Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Parallel Queries and PostGIS |
Date: | 2016-03-28 17:01:36 |
Message-ID: | CACowWR24L5ByU6+g_HOqVNjuDDN7jOOtkatcci=46c5aVeSvwg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Mar 28, 2016 at 9:45 AM, Stephen Frost <sfrost(at)snowman(dot)net> wrote:
> Paul,
>
> * Paul Ramsey (pramsey(at)cleverelephant(dot)ca) wrote:
>> I spent some time over the weekend trying out the different modes of
>> parallel query (seq scan, aggregate, join) in combination with PostGIS
>> and have written up the results here:
>>
>> http://blog.cleverelephant.ca/2016/03/parallel-postgis.html
>
> Neat!
>
> Regarding aggregate parallelism and the cascaded union approach, though
> I imagine in other cases as well, it seems like having a
> "final-per-worker" function for aggregates would be useful.
>
> Without actually looking at the code at all, it seems like that wouldn't
> be terribly difficult to add.
>
> Would you agree that it'd be helpful to have for making the st_union()
> work better in parallel?
For our particular situation w/ ST_Union, yes, it would be ideal to be
able to run a worker-side combine function as well as the master-side
one. Although the cascaded union would be less effective spread out
over N nodes, doing it only once per worker, rather than every N
records would minimize the loss of effectiveness.
P
From | Date | Subject | |
---|---|---|---|
Next Message | Petr Jediný | 2016-03-28 17:10:08 | Re: BRIN is missing in multicolumn indexes documentation |
Previous Message | Stephen Frost | 2016-03-28 16:45:43 | Re: Parallel Queries and PostGIS |