Re: Optimizing FastPathTransferRelationLocks()
Heikki Linnakangas <hlinnaka@iki.fi>
From: Heikki Linnakangas <hlinnaka@iki.fi>
To: Fujii Masao <masao.fujii@oss.nttdata.com>,
pgsql-hackers@lists.postgresql.org
Date: 2024-11-15T22:15:45Z
Lists: pgsql-hackers
On 12/11/2024 03:16, Fujii Masao wrote: > Hi, > > I've identified some opportunities to optimize > FastPathTransferRelationLocks(), which transfers locks with a > specific lock tag from per-backend fast- path arrays to the shared > hash table. The attached patch includes these enhancements. > > Currently, FastPathTransferRelationLocks() recalculates the fast- > path group on each loop iteration, even though it stays the same. > This patch updates the function to calculate the group once and > reuse it, improving efficiency. Makes sense. GetLockConflicts() has similar code, the same optimizations would apply there too. > The patch also extends the function's logic to skip not only > backends from a different database but also backends with pid=0 > (which don’t hold fast-path locks) and groups with no registered > fast-path locks. > > Since MyProc->pid is reset to 0 when a backend exits but MyProc- > >databaseId remains set, checking only databaseId isn’t enough. > Backends with pid=0 also should be skipped. Hmm, a PGPROC entry that's not in use would also have proc->fpLockBits[group] == 0, so I'm not sure if the check for proc->pid == 0 is necessary. And perhaps we should start clearing databaseid on backend exit. -- Heikki Linnakangas Neon (https://neon.tech)
Commits
-
Optimize iteration over PGPROC for fast-path lock searches.
- e80171d57c25 18.0 landed
-
Increase the number of fast-path lock slots
- c4d5cb71d229 18.0 cited