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
