Feedback-ID: id4a34324:Fastmail
Date: Fri, 13 Feb 2026 16:13:39 -0500
From: Andres Freund <andres@anarazel.de>
To: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
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: <aY-MRFnzTDJO265s@alap3.anarazel.de>
References: <CAKAnmm+USTr5MeKuyrAvbCjHqbSFbZ+czJsV7fPYt9nECQkf-A@mail.gmail.com>
 <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>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <aY779Gu3rQwJ4Erq@ip-10-97-1-34.eu-west-3.compute.internal>
Archived-At: <https://www.postgresql.org/message-id/aY-MRFnzTDJO265s%40alap3.anarazel.de>
Precedence: bulk

Hi,

On 2026-02-13 10:24:52 +0000, Bertrand Drouvot wrote:
> On Fri, Feb 13, 2026 at 04:36:57PM +0900, Michael Paquier wrote:
> > On Tue, Feb 10, 2026 at 07:30:50AM +0000, Bertrand Drouvot wrote:
> > > New rebase due to 73d60ac385a.
> > So my suggestion for the moment would be to be more frugal (yeah I
> > know, sorry..) and limit ourselves to four fields: deadlock_timeout,
> > requests, fastpath and timeouts.  Three fields to compare with
> > requests, one for each GUC.
> 
> 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.

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?

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.


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.


> @@ -17,6 +17,7 @@
>  #include "postmaster/pgarch.h"	/* for MAX_XFN_CHARS */
>  #include "replication/conflict.h"
>  #include "replication/worker_internal.h"
> +#include "storage/lock.h"
>  #include "utils/backend_progress.h" /* for backward compatibility */	/* IWYU pragma: export */
>  #include "utils/backend_status.h"	/* for backward compatibility */	/* IWYU pragma: export */
>  #include "utils/pgstat_kind.h"
> @@ -342,6 +343,25 @@ typedef struct PgStat_IO
>  	PgStat_BktypeIO stats[BACKEND_NUM_TYPES];
>  } PgStat_IO;

I don't like the amount of headers this addition will indirectly include in a
lot of places.

I'm also pretty unhappy about an include of access/transam.h recently having
been added. And worker_internal.h quite obviously, given the name, has no
business being included here, and also includes a lot more. Grrr.  I'll start
a thread.

Greetings,

Andres Freund