Parameter · Replication / Subscribers
max_parallel_apply_workers_per_subscription
Maximum number of parallel apply workers per subscription.
- Default:
2 - Type: integer
- Range: 0 … 1024
- Applies: Reload
In plain words
For a subscription created with streaming = parallel, a large transaction that is still running on the publisher is streamed in chunks and can be applied by a separate parallel apply worker while the main apply worker continues. This sets how many such helpers one subscription may use at the same time.
For DBAs and operators
Added in PostgreSQL 16 together with streaming = parallel, which is the default for new subscriptions since PostgreSQL 18. Without parallel apply, a streamed transaction is spooled to a file on the subscriber and applied only after it commits on the publisher, which delays big transactions.
Workers are taken from max_logical_replication_workers. When none is available the leader falls back to spooling, so too few helpers costs speed, not correctness.
0 disables parallel apply. Observe in pg_stat_subscription where worker_type = 'parallel apply'. Also controlled on the publisher side by logical_decoding_work_mem: in-progress transactions are streamed only once the decoded changes held in memory exceed it.
How to change it
Change in postgresql.conf or ALTER SYSTEM, then run SELECT pg_reload_conf().
See it in context
Logical replication workers Logical replication Parallel and background workers Logical decoding and ReorderBuffer
Related parameters
max_logical_replication_workers max_sync_workers_per_subscription logical_decoding_work_mem