Horton
Menu

Re: Adding locks statistics

Michael Paquier <michael@paquier.xyz>

View thread
From: Michael Paquier <michael@paquier.xyz>
To: Andres Freund <andres@anarazel.de>
Cc: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>, Jeff Davis <pgsql@j-davis.com>, Greg Sabino Mullane <htamfids@gmail.com>, pgsql-hackers@lists.postgresql.org
Date: 2026-02-16T04:18:32Z
Lists: pgsql-hackers 
On Fri, Feb 13, 2026 at 04:13:39PM -0500, Andres Freund wrote:
> I'm not sure that it's unproblematic to add multiple pgstat count calls to
> every lock acquisition, particularly if it's a fastpath acquisition or a
> virtualxid lock. Notably these are external function calls, not just
> increments of a counter in an inline function.

Right.  I am not completely sure if this is really free, either,
particularly for a fastpath lock that we want to be..  Faster.

> What I would actually count is the amount of time waiting for locks, that
> seems vastly more useful than the number of acquisitions.  We already do a
> GetCurrentTimestamp() inside the timer activations for deadlock timeout, we
> probably can figure out a way to reuse that to reduce the increase in overhead
> due to timing.  We could also just count the wait time after the deadlock
> check has run.

That sounds like an interesting suggestion, yes.  That's not going to
be bounded by performance if we know that we are already waiting.
--
Michael

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Fix injection point detach timing problem in TAP test for lock stats

  2. Use single LWLock for lock statistics in pgstats

  3. Add tests for lock statistics, take two

  4. Remove isolation test lock-stats

  5. Avoid including clog.h in proc.h

  6. Don't include storage/lock.h in so many headers

  7. Add support for lock statistics in pgstats

  8. Move some code blocks in lock.c and proc.c

  9. Move declarations related to locktags from lock.h to new locktag.h