From: | Bertrand Drouvot <bertranddrouvot(dot)pg(at)gmail(dot)com> |
---|---|
To: | Michael Paquier <michael(at)paquier(dot)xyz> |
Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Adding wait events statistics |
Date: | 2025-07-08 04:46:28 |
Message-ID: | aGyipN8hqEfsx7iQ@ip-10-97-1-34.eu-west-3.compute.internal |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
On Tue, Jul 08, 2025 at 09:36:53AM +0900, Michael Paquier wrote:
> On Mon, Jul 07, 2025 at 03:07:12PM +0000, Bertrand Drouvot wrote:
>
> > I think the question is: if the extension owner does not increment it, do we want
> > to do it in core on their behalf? I'm not sure as it's still up to them to make
> > use of custom wait events: so some of them will, some not, making the "in core"
> > counters not consistent depending of the extension. That could result in end
> > users asking why they see counters for some and not for some.
>
> My take would be yes. That feels more natural than ignoring things.
Yeah ignoring the custom wait events would not make sense, but "waiting" to see
if there is a need/ask could have made sense.
> > I was thinking to just start with "in core" wait events and see if there is a
> > need/ask to expand it to custom wait events. Thoughts?
>
> This statement is perhaps true. Now we do use custom wait events even
> in contrib/ modules, so the move feels natural to me.
Okay, I had in mind to start with something simpler that would have covered the
waste majority (I think) of end users's needs but will look at it for v2 then.
> > I'm not sure that would be simpler (or maybe that would simplify the perl
> > script a bit) but I think that might complicate the C code a bit. I mean, given
> > a wait_event_info we'd need to know in which array to increment the related wait
> > event counter. So, (at least) some switch on the wait class would be needed (and
> > that would probably need to be generated by the perl script, so I'm not sure
> > that would simplify the perl script after all).
>
> Noted.
>
> > Also in pg_stat_get_wait_event(), we'd need to iterate on all the arrays so
> > we'd need to know and identify them.
>
> Yes, you may need some level of meta-data generated for the wait
> classes generated when the perl script generating this data is run.
> It would be nice to the footprint of the code generated minimal if we
> can. It's one of these things where I would try both approaches,
Let's see what a multi arrays approach would look like and decide.
> > Yeah, my doubt was more about the hashing distribution if all the keys have
> > the exact same bits (the upper 32 bits) sets to zero (which is what using a
> > uint32 key would produce).
>
> Hmm. Not sure about that, but that would not be difficult to check.
> It is true that it would not be a good thing if all the stats get
> pushed through the same partition in the pgstat dshash table, but I'm
> pretty sure that we don't need to worry much about that, like for
> neighboring OIDs.
Probably yes, will try to figure out though, out of curiosity (I think that would
be good to know generally speaking).
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2025-07-08 04:59:32 | Re: Instability of pg_walsummary/002_blocks.pl due to timing |
Previous Message | Andres Freund | 2025-07-08 03:22:12 | Re: postmaster uses more CPU in 18 beta1 with io_method=io_uring |