| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Michael Paquier <michael(at)paquier(dot)xyz> |
| Cc: | Jeff Davis <pgsql(at)j-davis(dot)com>, Greg Sabino Mullane <htamfids(at)gmail(dot)com>, Bertrand Drouvot <bertranddrouvot(dot)pg(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: Adding locks statistics |
| Date: | 2025-08-11 23:49:45 |
| Message-ID: | 3282672.1754956185@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Michael Paquier <michael(at)paquier(dot)xyz> writes:
> On Mon, Aug 11, 2025 at 02:53:58PM -0700, Jeff Davis wrote:
>> Can you describe your use case? I'd like to understand whether this is
>> useful for users, hackers, or both.
> This is a DBA feature, so the questions I'd ask myself are basically:
> - Is there any decision-making where these numbers would help? These
> decisions would shape in tweaking the configuration of the server or
> the application to as we move from a "bad" number trend to a "good"
> number trend.
> - What would be good numbers? In this case, most likely a threshold
> reached over a certain period of time.
> - Would these new stats overlap with similar statistics gathered in
> the system, creating duplication and bloat in the pgstats for no real
> gain?
I'm also wondering why slicing the numbers in this particular way
(i.e., aggregating by locktype) is a helpful way to look at the data.
Maybe it's just what you want, but that's not obvious to me.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Paquier | 2025-08-11 23:58:47 | Re: Invalid remote sampling test in postgres_fdw. |
| Previous Message | Michael Paquier | 2025-08-11 23:44:58 | Re: Adding locks statistics |