Feedback-ID: i0fe9450f:Fastmail
Date: Mon, 16 Feb 2026 13:18:32 +0900
From: Michael Paquier <michael@paquier.xyz>
To: Andres Freund <andres@anarazel.de>
Cc: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>,
	Jeff Davis <pgsql@j-davis.com>,
	Greg Sabino Mullane <htamfids@gmail.com>,
	pgsql-hackers@lists.postgresql.org
Subject: Re: Adding locks statistics
Message-ID: <aZKamOyj4IHcSDZ4@paquier.xyz>
References: <87c3170d0645cec732f0d7b2969c75db1b3c86c6.camel@j-davis.com>
 <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>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="91fVdNl6tr1yRgCU"
Content-Disposition: inline
In-Reply-To: <aY-MRFnzTDJO265s@alap3.anarazel.de>
Archived-At: <https://www.postgresql.org/message-id/aZKamOyj4IHcSDZ4%40paquier.xyz>
Precedence: bulk


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

On Fri, Feb 13, 2026 at 04:13:39PM -0500, Andres Freund wrote:
> 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.

Right.  I am not completely sure if this is really free, either,
particularly for a fastpath lock that we want to be..  Faster.

> 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.

That sounds like an interesting suggestion, yes.  That's not going to
be bounded by performance if we know that we are already waiting.
--
Michael

--91fVdNl6tr1yRgCU
Content-Type: application/pgp-signature; name=signature.asc

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEG72nH6vTowiyblFKnvQgOdbyQH0FAmmSmpgACgkQnvQgOdby
QH1iKxAAoYkWfb6WihTkzRHkDqpvt/gQqX9Qo4TUqdlJv0QB+whKEGfxRjtER4vz
Sp/OoPDdRFGAVA/2FoZZIaeldz9BakJRL0hvmmq2JqB+8Z+G+JRI/jSKYK5qsvEB
U4ePH112U6pb0GUzEa/d141FXYNDLP3n94gShJ2bOg9LFK4eIPjcf1YdAtHRoaVc
aVC8h58qDSG+xjJM3lQc+WcFP+ycD/Ag17Q2Ob2XT7HeB62gi+/OeCEzQPa9hwPb
glOmw3xphOIb7ks8oTmp5Ti2v+HXqLO8EYXzf2GBFr3ooW8WqHDGOLdoj4vUWw/3
mxPMZQd2XoVM5KcnF4MgZCJdBTX5Bi6Cu1k4MMvLBcFjOOHs9bWMI9I/ZaXEQfwB
ShIi0VLJTcRlhjVR6O49gK3ZAN+1WKaTn9WLW31jNO04Zfy78MokGn10XBycwxts
t41S30JX28kWy+aAjSGRRy4qgnuutbDxY7n7OBW0Jxz972m8kOxZGeK7DboeNi9E
HyOSnWBg+oZ78bbRwfjN4cgYIuFO2MP7zjBrk8uLq2P3pFB7mbUh/ZxXs0mtkiwv
Abv26++h6g/YdeoUlmr8q+Yt8p2KLcyE+eOEvwbMHK1LXCsonqAx5WdrOUgsWrw0
ZCRSGsP/XKSTTdCl4j50cQNRbgae3ZkLr0HzStkfZPy7QLHJOlk=
=bkaU
-----END PGP SIGNATURE-----

--91fVdNl6tr1yRgCU--