Re: Adding wait events statistics

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