Hi, On Fri, Feb 13, 2026 at 04:13:39PM -0500, Andres Freund wrote: > Hi, > > 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 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. > 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? > 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? I think that keeping requests would make sense to be able to get the average wait time per request. Regards, -- Bertrand Drouvot PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services: https://aws.amazon.com
