Feedback-ID: i0fe9450f:Fastmail
Date: Tue, 12 Aug 2025 08:44:58 +0900
From: Michael Paquier <michael@paquier.xyz>
To: Jeff Davis <pgsql@j-davis.com>
Cc: Greg Sabino Mullane <htamfids@gmail.com>,
	Bertrand Drouvot <bertranddrouvot.pg@gmail.com>,
	pgsql-hackers@lists.postgresql.org
Subject: Re: Adding locks statistics
Message-ID: <aJqAei83uRWV93bM@paquier.xyz>
References: <aIyNxBWFCybgBZBS@ip-10-97-1-34.eu-west-3.compute.internal>
 <CAKAnmm+USTr5MeKuyrAvbCjHqbSFbZ+czJsV7fPYt9nECQkf-A@mail.gmail.com>
 <87c3170d0645cec732f0d7b2969c75db1b3c86c6.camel@j-davis.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="44fPoQZ1OaD1Z1ow"
Content-Disposition: inline
In-Reply-To: <87c3170d0645cec732f0d7b2969c75db1b3c86c6.camel@j-davis.com>
Archived-At: 
 <https://www.postgresql.org/message-id/aJqAei83uRWV93bM%40paquier.xyz>
Precedence: bulk


--44fPoQZ1OaD1Z1ow
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mon, Aug 11, 2025 at 02:53:58PM -0700, Jeff Davis wrote:
> On Mon, 2025-08-11 at 13:54 -0400, Greg Sabino Mullane wrote:
> > Great idea.=A0+1.=A0Here is a quick overall review to get things starte=
d.
>=20
> Can you describe your use case? I'd like to understand whether this is
> useful for users, hackers, or both.

This is a DBA feature, so the questions I'd ask myself are basically:
- Is there any decision-making where these numbers would help?  These
decisions would shape in tweaking the configuration of the server or
the application to as we move from a "bad" number trend to a "good"
number trend.
- What would be good numbers?  In this case, most likely a threshold
reached over a certain period of time.
- Would these new stats overlap with similar statistics gathered in
the system, creating duplication and bloat in the pgstats for no real
gain?

Looking at the patch, the data gathered is this, and I don't think
that we have metrics gathered in the system to get an idea of the
contention in this area, for timeouts and deadlocks:
+	PgStat_Counter requests;
+	PgStat_Counter waits;
+	PgStat_Counter timeouts;
+	PgStat_Counter deadlock_timeouts;
+	PgStat_Counter deadlocks;
+	PgStat_Counter fastpath;

Isn't the "deadlock_timeout" one an overlap between timeout and
deadlock?  Having three counters to track two concepts seems strange
to me.

Regarding the fastpath locking, you'd want to optimize the fastpath to
be close to the number of requests.  If you had these numbers, one
thing that I could see a DBA do is tune max_locks_per_transaction,
which is what influences the per-backend limit of fast-path locks,
with FastPathLockGroupsPerBackend.

Using static counters for the pending data is going to be necessary
when these are called in critical sections, which is I guess why
you've done it this way, right?
--
Michael

--44fPoQZ1OaD1Z1ow
Content-Type: application/pgp-signature; name="signature.asc"

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

iQIzBAABCgAdFiEEG72nH6vTowiyblFKnvQgOdbyQH0FAmiagHoACgkQnvQgOdby
QH1dpQ/9H4cjXFaY9cpDqJFvcEGFMrF0cluodAlT06sc5JqmxGfByhDmJebkPMip
iEh8JDFrquaKFPCLsaR706Yb0mimVeWHLIx800Bd7fPiUjc+m1Ha67I292ALWuj4
wJRQOEopO+iOoJ/IBkejaW5fZud3XNIx/Z2OZoeLrPzPiBVJCtoVS/nwdYbCAuyh
xCeJHQP3IF7EN6EPxzK5fpecwW0vscDR/3iDQqgbLIiiOroF6T4G1nv+CwnT932f
GLRhKoXYNOIXaVloM2x0cx1XZDG3LqQiEplT6R2DUUHfaIptT+pPkQV3PbR50+vw
8mr8AcNMJQpH/cLnVd798GaSSxMsg+sRMM5WXbdcCqSs3y8MKs3cDtJ7klfDgGsF
/P3mhmf92uM3s3nu7LtoYn4nn5ZONQBRG/Aju+88be5uw+a7f7oPQq8eeIQyEoIe
zl8PfpLT+gYtWDyl+lQAiVn1Lj5tTppywpW3WeUDLgvP+bM8HddkKka2DYF2h8RF
wg4NZnPRH7xE+izwU90nQYIihNG4HUQY+ejTJXUOqdYWeI80xaIHxl8hZard9RWr
dmbVLMy14iyUgFwI6Yj8Y52+8pxsuBorkaGlMEoGij67xotfoi0bHI14CPjs1y9X
voU3/e2BDvoSWdOqAjNT2QduXru2OEgei7EABgRSUr67NiiGmzA=
=RKBq
-----END PGP SIGNATURE-----

--44fPoQZ1OaD1Z1ow--