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 The TL:DR; is basically * With some adjustments to function COST both parallel sequence scan and parallel aggregation deliver very good parallel performance results. * The cost adjustments for sequence scan and aggregate scan are not consistent in magnitude. * Parallel join does not seem to work for PostGIS indexes yet, but perhaps there is some magic to learn from PostgreSQL core on that. The two findings at the end are ones that need input from parallel query masters... We recognize we'll have to adjust costs to that our particular use case (very CPU-intensive calculation per function) is planned better, but it seems like different query modes are interpreting costs in order-of-magnitude different ways in building plans. Parallel join would be a huge win, so some help/pointers on figuring out why it's not coming into play when our gist operators are in effect would be helpful. Happy Easter to you all, P -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
