Hi,
On Tue, Jul 08, 2025 at 04:46:28AM +0000, Bertrand Drouvot wrote:
> On Tue, Jul 08, 2025 at 09:36:53AM +0900, Michael Paquier wrote:
> > 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,
I did some testing and experiments and I think an "hybrid" approach mixing multiple
arrays and one "global" one is the best approach.
So, something like:
"
ClassInfo LWLockClassInfo = {
.numberOfEvents = NB_LWLOCK_WAIT_EVENTS,
.pendingCounts = PendingWaitEventStats.lwlock_counts
};
WaitClassInfo LockClassInfo = {
.numberOfEvents = NB_LOCK_WAIT_EVENTS,
.pendingCounts = PendingWaitEventStats.lock_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,
};
"
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.
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).
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
