3 ms·
We've been investigating using these features for some compute intensive workloads to see if we can keep some things inside the database that would normally hav
by zmmmmm 7y ago
We've been investigating using these features for some compute intensive workloads to see if we can keep some things inside the database that would normally have to break out to a separate compute service. The biggest problem really is this:
> .... if a parallel plan is not produced, refer to the PostgreSQL documentation on parallelism for details.
That is, there are a number of incidental features of queries that can silently disable parallelism. It becomes an art of knowing what will trip it off and another thing you have to test and think about while working with your queries.
Other than that however, it's extremely powerful to be able to use these features and I'm hopeful we'll be able to avoid a whole lot of bespoke compute services we'd otherwise need to make just to do certain compute operations in a timely manner.
- rosser 7y agoI 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.