Here is one fair warning about new PostgreSQL 9.6 (written 2016/12 for pg 9.6.1) – parallel processing of a query works only for a plain select. But if you embed the same query into CREATE TABLE or CREATE MATERIALIZED VIEW command processing is NEVER parallel even if you try to force it using setting “force_parallel_mode”. It seems to be expected behavior “by design” – http://stackoverflow.com/questions/40015867/parallel-queries-on-cte-for-writing-operations-in-postgresql
In fact almost in all my cases of a such commands I got worse or even very very bad query plan and these queries run very badly in general in comparison with latest PG 9.5
On the other hand our read only database for analytical queries now performs much better with plain SELECT commands because almost all now run in parallel and are therefore very quick…
Update: Looks like PostgreSQL 9.6 requires higher setting of work_mem than 9.5 – I fiddled with query plans of badly running queries and found that just by changes of work_mem setting in session I can get costs from “Sort (cost=807568233.23..807568267.50 rows=13709 width=105)” for work_mem=32MB down to “Sort (cost=151127.62..151161.89 rows=13709 width=105)” for work_mem=64MB on the same query…