| From: | Andres Freund <andres(at)anarazel(dot)de> |
|---|---|
| To: | Bertrand Drouvot <bertranddrouvot(dot)pg(at)gmail(dot)com> |
| Cc: | Michael Paquier <michael(at)paquier(dot)xyz>, 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-20 16:02:49 |
| Message-ID: | isi5wszczhusgjetxwe6khxa5mbm5jms3msmbhwl73jktxw7ic@3mympoumua76 |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi,
On 2026-02-20 06:38:07 +0000, Bertrand Drouvot wrote:
> > If the delay is very
> > short it's probably also not that interesting to track, but I guess that's
> > debatable.
>
> v6 was introducing timed_waits so that we have:
>
> waits
> timed_waits
> wait_time
> fastpath_exceeded
>
> timed_waits and wait_time were incremented together and waits was incremented
> unconditionally. I like the idea of being able to track the numbers of waits
> whatever the value of log_lock_waits (or the new track_lock_timing) is. Also
> one could compare waits vs timed_waits.
How could a user benefit from that split? To me this is pointless number
gathering that wastes resources and confuses users.
Seriously, youre introducing stats left and right, you really need to stop and
first carefully think about what those stats could possibly be useful
for. Before writing a patch implementing the stats.
Greetings,
Andres Freund
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2026-02-20 16:07:42 | Re: ecdh support causes unnecessary roundtrips |
| Previous Message | Bertrand Drouvot | 2026-02-20 15:55:27 | Re: Flush some statistics within running transactions |