|
Controls when the database server acquires individual row locks for a table.
On, Off
On
| PUBLIC role | For current user | For other users | |
|---|---|---|---|
| Allowed to set permanently? | Yes, with SET ANY PUBLIC OPTION | Yes | Yes, with SET ANY PUBLIC OPTION |
| Allowed to set temporarily? | Yes, with SET ANY PUBLIC OPTION | Yes (current connection only) | No |
If the subsume_row_locks option is On (the default) then whenever a table t is locked exclusively with LOCK TABLE t IN EXCLUSIVE MODE, the database server no longer acquires individual row locks for t.
This can result in a significant performance improvement if extensive updates are made to t in a single transaction, especially if t is large relative to cache size. It also allows for atomic update operations that are larger than the lock table can currently handle (approximately 2-4 million rows).
When this option is On, keyset cursors over a table locked in this fashion return row changed warnings for every row in the cursor, if any row in the database has been modified. The database server could turn an updatable cursor with an ORDER BY into a keyset cursor as a result.