Re: Optimizing FastPathTransferRelationLocks()
От | Heikki Linnakangas |
---|---|
Тема | Re: Optimizing FastPathTransferRelationLocks() |
Дата | |
Msg-id | fa48b1d5-656b-4ce3-a3b8-4432eb592867@iki.fi обсуждение исходный текст |
Список | 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)
В списке pgsql-hackers по дате отправления: