{"Entry":{"collection":"guc","key":"max_parallel_maintenance_workers","name":"max_parallel_maintenance_workers","aliases":[],"metadata":{"baseline":false,"boot_human":"Not specified","boot_val":null,"category":"Resource Usage / Worker Processes","category_zh":"","changed_in":["18"],"changes":[{"documentation_changed":false,"fields":{},"from":"10","status":"added","to":"11"},{"documentation_changed":true,"fields":{},"from":"12","status":"changed","to":"13"},{"documentation_changed":true,"fields":{},"from":"16","status":"changed","to":"17"},{"documentation_changed":true,"fields":{"category":{"from":"Resource Usage / Asynchronous Behavior","to":"Resource Usage / Worker Processes"}},"from":"17","status":"changed","to":"18"}],"content_hash":"873521f8fbe730555ebe193e01cfe0c52109b229dc2d659946ddbb6eeae41926","context":"","default_changed_in":[],"default_history":[{"from":"11","to":"19","value":"2"}],"editorial":{"advice":{"olap":"Analytical work can use a larger max_parallel_maintenance_workers, but multiply per-node memory and I/O by concurrent statements. Benchmark throughput under realistic worker contention rather than one isolated query.","oltp":"Set max_parallel_maintenance_workers from a concurrency budget, not core count alone. Protect latency-sensitive OLTP from report and maintenance bursts, and verify actual Workers Planned versus Workers Launched.","small":"Keep max_parallel_maintenance_workers conservative on a small host. More possible workers can reduce throughput through context switching and memory pressure even when a single query becomes faster."},"mechanism":["max_parallel_maintenance_workers caps workers requested by one supported maintenance command, such as parallel CREATE INDEX or VACUUM. The leader is additional and may also perform work.","The cap does not reserve workers or guarantee they will be available. Requests compete within max_parallel_workers and max_worker_processes, and operation-specific rules can choose fewer.","Parallel maintenance can multiply CPU and I/O pressure; CREATE INDEX memory follows maintenance-specific accounting rather than simply granting maintenance_work_mem independently to every worker. Its user context permits session- or transaction-local changes; newly performed or newly planned work sees the value."],"pitfalls":["Treating max_parallel_maintenance_workers as reserved capacity rather than an upper bound shared with other work.","Ignoring that parallel plans multiply CPU, I/O, and work_mem-limited nodes.","Benchmarking one query without concurrent worker contention.","Assuming planned workers will always be launched at execution time."],"references":[{"title":"PostgreSQL 19 Beta 4: max_parallel_maintenance_workers","url":"https://www.postgresql.org/docs/19/runtime-config-resource.html#GUC-MAX-PARALLEL-MAINTENANCE-WORKERS"},{"title":"PostgreSQL 19 release notes","url":"https://www.postgresql.org/docs/19/release-19.html"}],"related":["max_parallel_workers","max_worker_processes","maintenance_work_mem","maintenance_io_concurrency","max_parallel_workers_per_gather"],"summary":"max_parallel_maintenance_workers — Sets the maximum number of parallel processes per maintenance operation. Observed in PG11–19 Beta 4; its last measured boot default is 2 in PG19 Beta 4, with user context. This is a beta-snapshot fact and can change before PostgreSQL 19 GA."},"enumvals":[],"first_version":"11","group":"Resource Usage","group_slug":"resource","imported_at":"2026-09-27T17:57:31.712044+08:00","intro_commit":{"authored_at":"2018-02-02T13:25:55-05:00","discussion":["https://postgr.es/m/CAM3SWZQKM=Pzc=CAHzRixKjp2eO5Q0Jg1SoFQqeXFQ647JiwqQ@mail.gmail.com","https://postgr.es/m/CAH2-Wz=AxWqDoVvGU7dq856S4r6sJAj6DBn7VMtigkB33N5eyg@mail.gmail.com"],"hash":"9da0cc35284bdbe8d442d732963303ff0e0a40bc","subject":"Support parallel btree index builds.","url":"https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=9da0cc35284bdbe8d442d732963303ff0e0a40bc"},"key":"max_parallel_maintenance_workers","last_version":"20","max_val":"","min_val":"","name":"max_parallel_maintenance_workers","position":274,"present_in":["11","12","13","14","15","16","17","18","19","20"],"short_desc":"Sets the maximum number of parallel workers that can be started by a single utility command.","short_desc_zh":"","source_rev":"english-manuals:d71089114d347473a3647960d451817f072e21a44b10ab09b586a669c55d406a","unit":"","vartype":"integer"}},"Definition":{"Collection":"guc","Key":"max_parallel_maintenance_workers","SourceDatabase":"center","Version":"18","SourceTable":"guc","SourceKey":"max_parallel_maintenance_workers","SourceRevision":"english-manuals:d71089114d347473a3647960d451817f072e21a44b10ab09b586a669c55d406a","Facts":{"boot_val":"2","category":"Resource Usage / Worker Processes","context":"user","description":"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 when building a B-tree, GIN, or BRIN 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.","doc":{"anchor":"GUC-MAX-PARALLEL-MAINTENANCE-WORKERS","file":"runtime-config-resource.html","lang":"en","sha256":"2e207c599f0884dfbe594558c478a2c7c132578981071e980e2015f31dfce28c","slug":"18"},"documented":true,"enumvals":null,"extra_desc":null,"lang":"en","max_val":"1024","metadata_version":"18","min_val":"0","name":"max_parallel_maintenance_workers","short_desc":"Sets the maximum number of parallel processes per maintenance operation.","source":"pg-settings-source-snapshot","unit":null,"vartype":"integer"},"ManualEvidence":{"doc":{"anchor":"GUC-MAX-PARALLEL-MAINTENANCE-WORKERS","file":"runtime-config-resource.html","lang":"en","sha256":"2e207c599f0884dfbe594558c478a2c7c132578981071e980e2015f31dfce28c","slug":"18"}},"MeasuredEvidence":{"metadata_version":"18"}},"Text":{"Collection":"guc","Key":"max_parallel_maintenance_workers","SourceDatabase":"pgweb","Version":"18","Locale":"zh-Hans","Title":"max_parallel_maintenance_workers","Summary":"","BodyHTML":"\u003cp\u003e设置单个工具命令能够启动的并行工作进程的最大数量。目前，支持使用并行工作进程的工具命令包括：构建 B-树、GIN 或 BRIN索引时的 \u003ccode\u003eCREATE INDEX\u003c/code\u003e，以及不带 \u003ccode\u003eFULL\u003c/code\u003e 选项的 \u003ccode\u003eVACUUM\u003c/code\u003e。并行工作进程取自\u003ca href=\"/docs/18/runtime-config-resource.html#GUC-MAX-WORKER-PROCESSES\" rel=\"nofollow\"\u003emax_worker_processes\u003c/a\u003e建立的进程池，并受到\u003ca href=\"/docs/18/runtime-config-resource.html#GUC-MAX-PARALLEL-WORKERS\" rel=\"nofollow\"\u003emax_parallel_workers\u003c/a\u003e的限制。注意，运行时实际可用的工作进程可能不足请求的数量。此时，工具操作会使用少于预期的工作进程运行。默认值为 2。设为 0 会禁止工具命令使用并行工作进程。\u003c/p\u003e\u003cp\u003e注意，并行工具命令的内存消耗不应明显高于等效的非并行操作。这与并行查询的策略不同，后者的资源限制通常分别应用于每个工作进程。并行工具命令将 \u003ccode\u003emaintenance_work_mem\u003c/code\u003e 视为整个工具命令的资源上限，而不论使用多少个并行工作进程。不过，并行工具命令仍可能消耗多得多的 CPU 资源和 I/O 带宽。\u003c/p\u003e","SourceRevision":"2026-09-11@29c86d9","ContentHash":"b8040ca4c42a9087511ba80044d9e1bd137c50c32dd62403ee6b5fd4f16121bc","Payload":{"carried_from":"","carry_reason":"","doc_html":"\u003cp\u003e设置单个工具命令能够启动的并行工作进程的最大数量。目前，支持使用并行工作进程的工具命令包括：构建 B-树、GIN 或 BRIN索引时的 \u003ccode class=\"command\"\u003eCREATE INDEX\u003c/code\u003e，以及不带 \u003ccode class=\"literal\"\u003eFULL\u003c/code\u003e 选项的 \u003ccode class=\"command\"\u003eVACUUM\u003c/code\u003e。并行工作进程取自\u003ca href=\"/docs/18/runtime-config-resource.html#GUC-MAX-WORKER-PROCESSES\"\u003emax_worker_processes\u003c/a\u003e建立的进程池，并受到\u003ca href=\"/docs/18/runtime-config-resource.html#GUC-MAX-PARALLEL-WORKERS\"\u003emax_parallel_workers\u003c/a\u003e的限制。注意，运行时实际可用的工作进程可能不足请求的数量。此时，工具操作会使用少于预期的工作进程运行。默认值为 2。设为 0 会禁止工具命令使用并行工作进程。\u003c/p\u003e\u003cp\u003e注意，并行工具命令的内存消耗不应明显高于等效的非并行操作。这与并行查询的策略不同，后者的资源限制通常分别应用于每个工作进程。并行工具命令将 \u003ccode class=\"varname\"\u003emaintenance_work_mem\u003c/code\u003e 视为整个工具命令的资源上限，而不论使用多少个并行工作进程。不过，并行工具命令仍可能消耗多得多的 CPU 资源和 I/O 带宽。\u003c/p\u003e","doc_same_as":""}},"RequestedLocale":"zh-Hans","Fallback":false,"Versions":["11","12","13","14","15","16","17","18","19","20"],"Locales":["en","zh-Hans"],"Signatures":null,"Spellings":null,"SQLState":null,"Evidence":null}