On Tue, May 16, 2023 at 1:14 AM Michael Paquier <mich...@paquier.xyz> wrote: > These are the two things refactored in the patch, explaining the what. > The reason behind the why is to make the script in charge of > generating all these structures and functions consistent for all the > wait event classes, simply. Treating all the wait event classes > together eases greatly the generation of the documentation, so that it > is possible to enforce an ordering of the tables of each class used to > list each wait event type attached to them. Does this explanation > make sense?
Not really. At least not to me. Changing the code in dblink to use WAIT_EVENT_EXTENSION instead of PG_WAIT_EXTENSION doesn't help you automatically generate documentation in any way. It seems to me that your automatic generation code might need a special case for wait event types that contain only a single wait event. But that doesn't seem like a bad thing to have. Adding pgstat_get_wait_extension adds runtime cost for no corresponding benefit. Having a special case in the code to avoid that seems worthwhile. -- Robert Haas EDB: http://www.enterprisedb.com
