From: | Zaeem Hussain <zaeem(dot)hussain(at)gmail(dot)com> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Granulaur spinlock wait events |
Date: | 2025-08-08 18:19:18 |
Message-ID: | CA+XmnEaf0pogPwSjGS4R70ZLgw4e+NEeRoP6=XCDVFW8Wcqosg@mail.gmail.com |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
I am a software engineer with Google's AlloyDB. We recently implemented
more granular spinlock wait event tracking and I wanted to propose it here.
I can create a patch if the community here deems it suitable for
incorporating into postgres. Here is the overall idea:
We categorise the spinlocks based on the location (filename and line
number) where they are initialized (via SpinLockInit).
We change slock_t to a struct that contains the actual lock variable and an
id (we just need a byte for it). We also allocate a shared memory array
(128 entries by 128 bytes) for storing the filename:line_number
identifiers. During SpinLockInit, we use the filename:line_number combo of
the caller and do a lookup for it in the array, adding an entry if the
combination is not found. The index of the entry is the identifier that
will be stored in the lock struct. This identifier is then set in the
SpinDelayStatus which is then used to set the new wait event id when
reporting SpinDelay (we add a new wait event class for SpinLock). The name
of the wait event is of the form 'SpinLock_filename:linenum'.
Pros of this approach: The changes are pretty much limited to the spinlock
related files and the APIs for SpinLock initialization, acquisition and
release do not change. There is also no additional overhead during spinlock
acuire and release.
Cons of this approach: Overhead of storing the id with each lock and extra
work during SpinLockInit.
We adopted this approach internally since we did not notice performance
regressions in our tests. However, the platforms we run on with AlloyDB are
only a subset of what postgres supports, so I am open to doing additional
testing on my patch if there are suggestions (right now it passes 'make
check' on my local build).
I would appreciate any feedback and suggestions on this.
Zaeem
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2025-08-08 18:31:22 | Re: SCRAM pass-through authentication for postgres_fdw |
Previous Message | Sami Imseih | 2025-08-08 18:09:29 | Re: Improve LWLock tranche name visibility across backends |