Hi,
On Wed, Jul 09, 2025 at 09:56:10AM +0900, Michael Paquier wrote:
> On Tue, Jul 08, 2025 at 03:25:26PM +0000, Bertrand Drouvot wrote:
> > So, something like:
> >
> > ClassInfo LWLockClassInfo = {
> > .numberOfEvents = NB_LWLOCK_WAIT_EVENTS,
> > .pendingCounts = PendingWaitEventStats.lwlock_counts
> > };
> >
> > and then the "global" one:
> >
> > WaitClassInfo *AllWaitClasses[] = {
> > NULL, /* gap - no class with ID 0 */
> > &LWLockClassInfo,
> > NULL, /* gap - no class with ID 2 */
> > &LockClassInfo,
> > &BufferPinClassInfo,
> > &ActivityClassInfo,
> > &ClientClassInfo,
> > &ExtensionClassInfo,
> > &IPCClassInfo,
> > &TimeoutClassInfo,
> > &IOClassInfo,
> > };
>
> Okay. I'm guessing that all this information is automatically built
> based on the contents of wait_event_names.txt (with some tweaks for
> the LWLock part?),
Yeah, fully generated by generate-wait_event_types.pl.
> > That way:
> >
> > - we do not need a mapping between ClassID and "Arrays" and the gaps
> > in the ClassID are handled. So we can acces directly the class of interest
> > knowing its classID.
> > - we can easily iterate (again no mapping needed) over all the pending stats
> > thanks to AllWaitClasses[]
> >
> > What do you think? It looks like the most elegant approach to me.
>
> I think that's pretty cool.
Yeah, but from what I can see the counter increment results in one more memory
read (as compared to v1), see [1]. So the code looks more simple but is more
expensive... I'll try to see what can be done to improve it.
> > Bonus point, as you can see above, while working on this approach I've been able
> > to remove storing the className and the array of eventName per wait class (would
> > have worked in v1 too).
>
> You mean the extra set of names generated?
Yeah those are not needed, the only thing that's important is that we ensure
that the counters and pending ones do contain the same "gap" (the LWLock ones),
so the the classID mapping is correct.
[1]: https://www.postgresql.org/message-id/aG4ZjQ1qKensHBOY%40ip-10-97-1-34.eu-west-3.compute.internal
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com