Re: Adding locks statistics

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Bertrand Drouvot <bertranddrouvot(dot)pg(at)gmail(dot)com>
Cc: Andres Freund <andres(at)anarazel(dot)de>, Jeff Davis <pgsql(at)j-davis(dot)com>, Greg Sabino Mullane <htamfids(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Adding locks statistics
Date: 2026-03-18 08:15:27
Message-ID: abpfH33mR4Mp9dtO@paquier.xyz
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message zengman 2026-03-18 08:20:14 Re: SQL Property Graph Queries (SQL/PGQ)
Previous Message Amit Kapila 2026-03-18 08:14:21 Re: Skipping schema changes in publication