Skip to content

Instantly share code, notes, and snippets.

@pramsey
Created March 25, 2016 19:18
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save pramsey/ff7cbf70dbe581189565 to your computer and use it in GitHub Desktop.
Save pramsey/ff7cbf70dbe581189565 to your computer and use it in GitHub Desktop.
PostgreSQL Parallel GUC Documentation
max_parallel_degree 0
Sets the maximum degree of parallelism for an individual parallel
operation. Note that the requested number of workers may not actually
be available at runtime. Parallel workers are taken from the pool
of processes established by `max-worker-processes`
parallel_tuple_cost 0.1
Sets the planner's estimate of the cost of transferring a tuple
from a parallel worker process to another process.
The default is 0.1.
parallel_setup_cost 1000
Sets the planner's estimate of the cost of launching parallel worker
processes.
The default is 1000.
force_parallel_mode off|on
Allows the use of parallel queries for testing purposes even in cases
where no performance benefit is expected.
The allowed values of `force_parallel_mode` are
"off" (use parallel mode only when it is expected to improve
performance), "on" (force parallel query for all queries
for which it is thought to be safe), and "regress" (like
on, but with additional behavior changes to facilitate automated
regression testing).
More specifically, setting this value to "on" will add
a "Gather" node to the top of any query plan for which this
appears to be safe, so that the query runs inside of a parallel worker.
Even when a parallel worker is not available or cannot be used,
operations such as starting a subtransaction that would be prohibited
in a parallel query context will be prohibited unless the planner
believes that this will cause the query to fail. If failures or
unexpected results occur when this option is set, some functions used
by the query may need to be marked `PARALLEL UNSAFE`
(or, possibly, `PARALLEL RESTRICTED`).
Setting this value to "regress" has all of the same effects
as setting it to "on" plus some additional effect that are
intended to facilitate automated regression testing. Normally,
messages from a parallel worker are prefixed with a context line,
but a setting of "regress" suppresses this to guarantee
reproducible results. Also, the "Gather" nodes added to
plans by this setting are hidden from the `EXPLAIN` output
so that the output matches what would be obtained if this setting
were turned "off".
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment