Re: Optimizing FastPathTransferRelationLocks() - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Re: Optimizing FastPathTransferRelationLocks()
Date
Msg-id fa48b1d5-656b-4ce3-a3b8-4432eb592867@iki.fi
Whole thread Raw
List 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 by date:

Previous
From: Tom Lane
Date:
Subject: Re: Potential ABI breakage in upcoming minor releases
Next
From: Noah Misch
Date:
Subject: Re: Potential ABI breakage in upcoming minor releases