Re: Adding locks statistics - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: Adding locks statistics
Date
Msg-id aZKamOyj4IHcSDZ4@paquier.xyz
Whole thread Raw
In response to Re: Adding locks statistics  (Andres Freund <andres@anarazel.de>)
List 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

Attachment

pgsql-hackers by date:

Previous
From: Peter Smith
Date:
Subject: DOCS - pg_walsummary typo?
Next
From: Thomas Munro
Date:
Subject: Re: Questionable description about character sets