Re: Introduce WAIT_EVENT_EXTENSION and WAIT_EVENT_BUFFER_PIN
От | Michael Paquier |
---|---|
Тема | Re: Introduce WAIT_EVENT_EXTENSION and WAIT_EVENT_BUFFER_PIN |
Дата | |
Msg-id | ZGVZum/iFF9Z1N6w@paquier.xyz обсуждение исходный текст |
Ответ на | Re: Introduce WAIT_EVENT_EXTENSION and WAIT_EVENT_BUFFER_PIN (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: Introduce WAIT_EVENT_EXTENSION and WAIT_EVENT_BUFFER_PIN
|
Список | pgsql-hackers |
On Wed, May 17, 2023 at 09:22:19AM -0400, Robert Haas wrote: > 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. Okay. We are going to need an approach similar to what's done for src/backend/nodes where two things are generated in order to be able to have some of the wait event classes be treated as exceptions in the switch calling each function (pgstat_get_wait_event). I'd assume: - Create the code calling the functions automatically, say in a wait_event_type.switch.c or something like that. If a class has one single element, generate the code from it. - Create a second file with the functions and their internals, as the patch does now (like wait_event_type.funcs.c?), discarding classes with single elements. - Skip the creation of the enum structures for single-element classes, as well. Still it looks like the renaming of BufferPin would need to remain around to ease a bit the work of the script. Bertrand, what do you think? -- Michael
Вложения
В списке pgsql-hackers по дате отправления: