Re: Adding locks statistics - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: Adding locks statistics
Date
Msg-id abpfH33mR4Mp9dtO@paquier.xyz
Whole thread Raw
In response to Re: Adding locks statistics  (Bertrand Drouvot <bertranddrouvot.pg@gmail.com>)
Responses Re: Adding locks statistics
List pgsql-hackers
On Wed, Mar 18, 2026 at 04:36:04AM +0000, Bertrand Drouvot wrote:
>> 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.

Looking again at this patch, all the fields that you are adding are in
non-critical paths, so it looks fine by me to begin with this data
set.  We may want to document that for future readers of the code to
not add counter increments in the fast code paths, where performance
could matter.

Let's also drop 0003 with the GUC.  log_lock_waits is enabled by
default and we are in a wait path which would not be
performance-critical.

Regarding the isolation test, the new permutations add 4 pg_sleep()
calls at 500ms each, making the stats test longer.  It also looks like
the outputs are the same for the two alternate expected files?  Do you
think that it could be possible to move these tests to a new file,
perhaps cutting a bit the sleeps to make it faster?
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: Skipping schema changes in publication
Next
From: "zengman"
Date:
Subject: Re: SQL Property Graph Queries (SQL/PGQ)