Feedback-ID: id4a34324:Fastmail
Date: Mon, 16 Feb 2026 16:00:56 -0500
From: Andres Freund <andres@anarazel.de>
To: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
Cc: Michael Paquier <michael@paquier.xyz>, Jeff Davis <pgsql@j-davis.com>, 
	Greg Sabino Mullane <htamfids@gmail.com>, pgsql-hackers@lists.postgresql.org
Subject: Re: Adding locks statistics
Message-ID: <otjn7ykaezlueayyp7fppggkldw23ykh3i6ite2rqq4xh7dwvl@w5dvqqgvqf25>
References: <aJqAei83uRWV93bM@paquier.xyz>
 <aJsLc+S62xAbjncC@ip-10-97-1-34.eu-west-3.compute.internal>
 <1a236172c7dda72939e4293657a90536cce7dd16.camel@j-davis.com>
 <aJwMi6qWKNc/ygg9@ip-10-97-1-34.eu-west-3.compute.internal>
 <aUA7ymkrh/UpkJ6O@ip-10-97-1-34.eu-west-3.compute.internal>
 <aYreqqn3meYqPm1A@ip-10-97-1-34.eu-west-3.compute.internal>
 <aY7UmTIiBScP4rAq@paquier.xyz>
 <aY779Gu3rQwJ4Erq@ip-10-97-1-34.eu-west-3.compute.internal>
 <aY-MRFnzTDJO265s@alap3.anarazel.de>
 <aZLtDbGEqSN2MuRb@ip-10-97-1-34.eu-west-3.compute.internal>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <aZLtDbGEqSN2MuRb@ip-10-97-1-34.eu-west-3.compute.internal>
Archived-At: <https://www.postgresql.org/message-id/otjn7ykaezlueayyp7fppggkldw23ykh3i6ite2rqq4xh7dwvl%40w5dvqqgvqf25>
Precedence: bulk

Hi,

On 2026-02-16 10:10:21 +0000, Bertrand Drouvot wrote:
> On Fri, Feb 13, 2026 at 04:13:39PM -0500, Andres Freund wrote:
> > On 2026-02-13 10:24:52 +0000, Bertrand Drouvot wrote:
> > > 
> > > That's fine by me. We could still add the others in the future if we feel the
> > > need. Done that way in the attached.
> > 
> > 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.
> 
> Yeah, we could create inline functions instead.

I think unless you have a heck of a lot more of a usecase than "it's
information", counting every lock acqusition seems just worth ti.


> > I also don't really know what one would do with some of the information?
> > 
> > What does the number of virtualxid lock acquisitions tell you that the numbers
> > of transactions doesn't already tell you in a more understandable way?
> 
> I agree not that much, except being able to compute a transactions/virtualxid
> ratio or such. Also the idea was to report the same as pg_locks so that one
> could start sampling pg_locks if he needs more details.

I don't think that's worth adding overhead to something extremely frequently
happening.


> > What does it tell you that the deadlock checker ran N times? It notably
> > doesn't count deadlocks, it counts how often we checked for deadlocks.
> > 
> > The percentage of fastpath locks also seems not really informative, because
> > that could be because we ran out of space for fastpath locks, or because a
> > lock mode that's ineligible for fastpath locks was used.
> 
> Right, maybe we could add an "exceed fastpath slots" or such counter?

That I could get behind.


> > 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.
> 
> Yeah, providing the wait_time would be great. Just to be sure, are you suggesting
> to remove all the fields (i.e requests, timeouts, deadlock_timeouts and fastpath)
> and just add a wait_time field instead?

Well, I'd maybe make it waits, wait_time and perhaps fastpath exceeded.


> I think that keeping requests would make sense to be able to get the average
> wait time per request.

I don't think I'd request for that (as that would require counting in the
normal case), I'd use the number of waits.


I don't think you have provided any actual motivation for why it's worth the
expense to track the number of lock requests.  Just trackings stats that
nobody has a usecase for that are not free to collect makes no sense.

Greetings,

Andres Freund