Refactor GetLockStatusData() by skipping unused backends and groups

From: Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Refactor GetLockStatusData() by skipping unused backends and groups
Date: 2024-10-21 00:19:49
Message-ID: a0a00c44-31e9-4c67-9846-fb9636213ac9@oss.nttdata.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

Attachment Content-Type Size
v1-0001-Refactor-GetLockStatusData-to-skip-backends-group.patch text/plain 3.4 KB

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Ajin Cherian 2024-10-21 00:45:20 Re: Conflict Detection and Resolution
Previous Message jian he 2024-10-21 00:00:00 comment invalid link reference in Macros IF_NEED_REFILL_AND_NOT_EOF_CONTINUE copyfromparse.c