Re: Introduce WAIT_EVENT_EXTENSION and WAIT_EVENT_BUFFER_PIN

On Tue, May 16, 2023 at 1:14 AM Michael Paquier <michael(at)paquier(dot)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