I would try to think of it less as a matter of "incidental features... that can silently disable parallelism", than one of "operations that are incompatible wit

I would try to think of it less as a matter of "incidental features... that can silently disable parallelism", than one of "operations that are incompatible with parallel execution". Writing anything [0], locking rows (e.g., "SELECT ... FOR UPDATE"), being run in the context of a cursor or loop, invoking "PARALLEL UNSAFE" functions, and a subquery in a query that is already parallelized are all cases where it is not meaningful for the planner to try to parallelize, so it punts. Remember, also, that this is a young implementation. The PostgreSQL community's first priority is taking great care not to eat your data. They'll find more ways to safely parallelize things. [0] In 11+, you can get a parallel plan on, e.g., "CREATE TABLE ... AS" and "SELECT INTO", if the query is otherwise parallelizable.