Date: Wed, 18 Mar 2026 04:36:04 +0000
From: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
To: Andres Freund <andres@anarazel.de>
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: <abortN3ngqMcaBJ7@ip-10-97-1-34.eu-west-3.compute.internal>
References: <aY-MRFnzTDJO265s@alap3.anarazel.de>
 <aZLtDbGEqSN2MuRb@ip-10-97-1-34.eu-west-3.compute.internal>
 <otjn7ykaezlueayyp7fppggkldw23ykh3i6ite2rqq4xh7dwvl@w5dvqqgvqf25>
 <aZSYcsRmqh7grqJb@ip-10-97-1-34.eu-west-3.compute.internal>
 <aZaMXK90sRjSQBJP@paquier.xyz>
 <v76tz252usppu2turrn6wxiyyxmybzxhqck5b3amtsbzrc6yto@n26qnwvpkxqw>
 <aZgBTyzxWmPJL0Tt@ip-10-97-1-34.eu-west-3.compute.internal>
 <isi5wszczhusgjetxwe6khxa5mbm5jms3msmbhwl73jktxw7ic@3mympoumua76>
 <aZiZTX1l5pX+BOXn@ip-10-97-1-34.eu-west-3.compute.internal>
 <aaEoN1XexvGiFvYp@ip-10-97-1-34.eu-west-3.compute.internal>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="nK2xgkLTeiiswcxd"
Content-Disposition: inline
In-Reply-To: <aaEoN1XexvGiFvYp@ip-10-97-1-34.eu-west-3.compute.internal>
Archived-At: 
 <https://www.postgresql.org/message-id/abortN3ngqMcaBJ7%40ip-10-97-1-34.eu-west-3.compute.internal>
Precedence: bulk


--nK2xgkLTeiiswcxd
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

Hi,

On Fri, Feb 27, 2026 at 05:14:31AM +0000, Bertrand Drouvot wrote:
> 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).

PFA, a rebase due to fd6ecbfa75ff.

Regards,

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

--nK2xgkLTeiiswcxd
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment;
	filename="v9-0001-Add-lock-statistics.patch"