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?), so why not even if there are gaps as long as we
know the length of AllWaitClasses. The stats code would be simple by
doing an O(n^2) across the array when flushing the individual contents
of each wait event.
> 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.
> 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? Yes, I was getting the
impression while reading your patch that this did not require this
complexity when generating the code for the pending data. Getting rid
of this part would be a nice outcome.
--
Michael
