Refactor GetLockStatusData() by skipping unused backends and groups
Fujii Masao <masao.fujii@oss.nttdata.com>
From: Fujii Masao <masao.fujii@oss.nttdata.com>
To: pgsql-hackers@postgresql.org
Date: 2024-10-21T00:19:49Z
Lists: pgsql-hackers
Attachments
- v1-0001-Refactor-GetLockStatusData-to-skip-backends-group.patch (text/plain) patch v1-0001
Hi, While reading the fast-path lock code, I noticed that GetLockStatusData() checks all slots for every backend to gather fast-path lock data. However, backends with PID=0 don't hold fast-path locks, right? If so, we can improve efficiency by having GetLockStatusData() skip those backends early. Additionally, when GetLockStatusData() checks a backend, it currently goes through all the slots accross its groups. Each group has 16 slots, so if a backend has 4 groups (this can change depending on max_locks_per_transaction), that means checking 64 slots. Instead, we could refactor the function to skip groups without registered fast-path locks, improving performance. Since each set of 16 slots is packed into a uint32 variable (PGPROC->fpLockBits[i]), it’s easy to check if a group has any fast-path locks. I've attached a patch that implements these changes. This refactoring is especially useful when max_connections and max_locks_per_transaction are set high, as it reduces unnecessary checks across numerous slots. Regards, -- Fujii Masao Advanced Computing Technology Center Research and Development Headquarters NTT DATA CORPORATION
Commits
-
Refactor GetLockStatusData() to skip backends/groups without fast-path locks.
- 86c30cef4a4c 18.0 landed