Re: Configurable FP_LOCK_SLOTS_PER_BACKEND

On Mon, Aug 7, 2023 at 3:48 PM Tomas Vondra
<tomas(dot)vondra(at)enterprisedb(dot)com> wrote:
> Why would the access frequency be uniform? In particular, there's a huge
> variability in how long the locks need to exist - IIRC we may be keeping
> locks for tables for a long time, but not for indexes. From this POV it
> might be better to do fast-path locking for indexes, no?

If you're not using explicit transactions, you take a bunch of locks
at the start of a statement and then release all of them at the end.
None of the locks stick around so fast-path locking structure goes
through cycles where it starts out empty, fills up to N items, and
then goes back to empty. If you visualize it as a cache, we're
flushing the entire cache at the end of every operation.

If you run multiple statements in a transaction, the locks will be
kept until the end of the transaction, once acquired. So then you
could start with a small number and gradually accumulate more. But
then you're going to release them all at once at the end.

The main thing that matters here seems to be whether or not all of the
locks can go through the fast-path mechanism, or how many have to go
through the regular mechanism. It shouldn't matter, AFAICS, *which
ones* go through the fast-path mechanism. If you think it does, I'd
like to hear why - it's possible I'm missing something here.

> Maybe, but isn't that mostly what the regular non-fast-path locking
> does? Wouldn't that defeat the whole purpose of fast-path locking?

I don't think so. The main lock manager has two flaws that hinder
performance in comparison with the fast-path mechanism. The first, but
less important, one is that the data structures are just a lot
simpler. For access to a small number of fixed-size elements, a C
array is hard to beat, and the main lock manager data structures are a
lot more complex. The second one, which I think is more important, is
that we've essentially flipped the ordering of the primary key. In the
main lock manager, you start by hashing the locked object and that
gives you a partition number and you then take that partition lock.
Then, you iterate through a list of backends that have that object
locked. This means that if a lot of people are taking locks on the
same object, even if there's no actual conflict between the lock
modes, you still get a lot of contention. But in the fast-path
mechanism, it's reversed: first, you go to the shared memory *for your
backend* and then you search through it for the particular locked
object at issue. So basically the main lock manager treats the primary
key as (what, who) while the fast-path mechanism treats it as (who,
what). And that gets rid of a ton of contention because then different
backends locking the same object (in sufficiently weak lock modes)
never touch the same cache lines, so there's actually zero contention.
That is, I believe, the most important thing about the fast-path
locking system.

What I've just said is slightly complicated by the existence of
FastPathStrongRelationLockData, which is concurrently accessed by all
backends when using fast-path locking, but it's only read-only as
nobody actually takes a strong lock (like an AccessExclusiveLock on a
table). So you probably do get some cache line effects there, but
because it's read-only, they don't cause too much of a headache.

We do have to be careful that the overhead of checking multiple
locking data structures doesn't add up to a problem, for sure. But
there can still, I believe, be a lot of benefit in dividing up access
first by "who" and then by "what" for weak relation locks even if the
per-backend data structures become more complex. Or at least I hope
so.

--
Robert Haas
EDB: http://www.enterprisedb.com