| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | Bertrand Drouvot <bertranddrouvot(dot)pg(at)gmail(dot)com>, 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-02-16 04:18:32 |
| Message-ID: | aZKamOyj4IHcSDZ4@paquier.xyz |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Thomas Munro | 2026-02-16 04:35:41 | Re: Questionable description about character sets |
| Previous Message | Peter Smith | 2026-02-16 03:39:29 | DOCS - pg_walsummary typo? |