On Mon, Mar 28, 2016 at 9:45 AM, Stephen Frost <sfr...@snowman.net> wrote: > Paul, > > * Paul Ramsey (pram...@cleverelephant.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers