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  (Michael Paquier <michael@paquier.xyz>)
Список 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 по дате отправления:

Предыдущее
От: Jehan-Guillaume de Rorthais
Дата:
Сообщение: Re: Memory leak from ExecutorState context?
Следующее
От: Jeff Davis
Дата:
Сообщение: Re: Order changes in PG16 since ICU introduction