From: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi> |
---|---|
To: | Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Optimizing FastPathTransferRelationLocks() |
Date: | 2024-11-15 22:15:45 |
Message-ID: | fa48b1d5-656b-4ce3-a3b8-4432eb592867@iki.fi |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
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)
From | Date | Subject | |
---|---|---|---|
Next Message | Noah Misch | 2024-11-15 22:27:49 | Re: Potential ABI breakage in upcoming minor releases |
Previous Message | Tom Lane | 2024-11-15 21:13:16 | Re: Potential ABI breakage in upcoming minor releases |