Re: Optimizing FastPathTransferRelationLocks()

On 2024/11/16 7:15, Heikki Linnakangas wrote:
> 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.

Yes, I've updated the patch as suggested.


>> 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.

You're right. I've removed the check for proc->pid == 0.

Also I added a check for proc->fpLockBits[group] == 0 in GetLockConflicts().

The latest version of the patch is attached.


> And perhaps we should start clearing databaseid on backend exit.

Maybe, but I'm not sure if we really need this..

Regards,

-- 
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION