Sets the maximum number of parallel workers that can be started by a single utility command. Currently, the parallel utility commands that support the use of parallel workers are CREATE INDEX only when building a B-tree index, and VACUUM without
FULL option. Parallel workers are taken from the pool of processes established by max_worker_processes, limited by max_parallel_workers. Note that the requested number of workers may not actually be available at run time. If this occurs, the utility operation will run with fewer workers than expected. The default value is 2. Setting this value to 0 disables the use of parallel workers by utility commands.
Note that parallel utility commands should not consume substantially more memory than equivalent non-parallel operations. This strategy differs from that of parallel query, where resource limits generally apply per worker process. Parallel utility commands treat the resource limit maintenance_work_mem as a limit to be applied to the entire utility command, regardless of the number of parallel worker processes. However, parallel utility commands may still consume substantially more CPU resources and I/O bandwidth.
- Postgres Create Index command hangs
- query to get the results of each row in table1 with a subquery of N maximum records found to meet a condition in table2
- Degrading import performance of PostgreSQL DB
- Geoserver WFS + PostgreSQL with large table impossibly slow
- Why does &amp;amp;amp;quot;explain analyzing&amp;amp;amp;quot; this query fnish fast (showing a parallel plan), while running the actual query without &amp;amp;amp;quot;explain analyze&amp;amp;amp;quot; doesn&amp;amp;amp;#39;t?