This controls how many pages or tuples of a single relation can be predicate-locked before the lock is promoted to covering the whole relation.
At a glance
| Property | Value |
|---|---|
| Parameter | max_pred_locks_per_relation |
| Category | Lock Management |
| Default | -2 |
| Value type | integer |
| Change scope | Reload (postgresql.conf, SIGHUP) |
| Available in | PostgreSQL 12, 13, 14, 15, 16, 17, 18, 19 (added in 12) |
What it does
This controls how many pages or tuples of a single relation can be predicate-locked before the lock is promoted to covering the whole relation. Values greater than or equal to zero mean an absolute limit, while negative values mean max_pred_locks_per_transaction divided by the absolute value of this setting. The default is -2, which keeps the behavior from previous versions of PostgreSQL. This parameter can only be set in the postgresql.conf file or on the server command line.
(Description quoted from the official PostgreSQL documentation.)
How to apply a change
Set it in postgresql.conf (or with ALTER SYSTEM) and reload with SELECT pg_reload_conf(); or pg_ctl reload — no restart needed.
Inspect the current value and source with SHOW max_pred_locks_per_relation; or SELECT name, setting, unit, context, source FROM pg_settings WHERE name = 'max_pred_locks_per_relation';.
Tuning guidance
This parameter is rarely a performance lever. Leave it at the default unless you have a specific, documented reason to change it, change it on one session or one role/database first, and confirm the effect with pg_settings and your own measurements before rolling it out cluster-wide.