Re: Adding locks statistics

Hi,

On Fri, Feb 20, 2026 at 05:26:37PM +0000, Bertrand Drouvot wrote:
> Hi,
>
> On Fri, Feb 20, 2026 at 11:02:49AM -0500, Andres Freund wrote:
> > Hi,
> >
> > How could a user benefit from that split? To me this is pointless number
> > gathering that wastes resources and confuses users.
>
> I was thinking that could be useful to know the distribution between "long" waits
> (greater than the deadlock timeout) among all the waits.
>
> If the vast majority are long waits that may indicate that the application is
> misbehaving (as opposed to a tiny percentage of long waits).
>
> I was also thinking to bring those stats per-backend (as a next step) and that
> could also probably be more useful (distribution per host for example, thanks to
> joining with pg_stat_activity).

As it seems that I'm the only one thinking that this split could be useful, I'm
removing it in the attached. We can still split later on if we have requests from
the field.

So, we're back to what we were discussing before the split. As in v7, 0003 is
adding the new GUC. So that we can see what having a new GUC implies in ProcSleep()
and we can just get rid of 0003 if we think the GUC is not worth the extra complexity
(I don't have a strong opinion on it but tempted to think that the extra GUC is
not worth it).

Regards,

--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com