Re: Optimizing FastPathTransferRelationLocks()

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)

In response to

Browse pgsql-hackers by date

  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