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
