Re: Introduce WAIT_EVENT_EXTENSION and WAIT_EVENT_BUFFER_PIN

Поиск
Список
Период
Сортировка
От Masahiro Ikeda
Тема Re: Introduce WAIT_EVENT_EXTENSION and WAIT_EVENT_BUFFER_PIN
Дата
Msg-id 4420c7fb5bf0894ce92d6857a8d041ed@oss.nttdata.com
обсуждение исходный текст
Ответ на Re: Introduce WAIT_EVENT_EXTENSION and WAIT_EVENT_BUFFER_PIN  ("Drouvot, Bertrand" <bertranddrouvot.pg@gmail.com>)
Ответы Re: Introduce WAIT_EVENT_EXTENSION and WAIT_EVENT_BUFFER_PIN  (Michael Paquier <michael@paquier.xyz>)
Список pgsql-hackers
Hi,

On 2023-05-19 16:48, Drouvot, Bertrand wrote:
> While at it, I think that making use of an enum might also be an open 
> door
> (need to think more about it) to allow extensions to set their own wait 
> event.
> Something like RequestNamedLWLockTranche()/GetNamedLWLockTranche() are 
> doing.
> 
> Currently we have "only" the "extension" wait event which is not that
> useful when
> there is multiples extensions installed in a database.

(Excuse me for cutting in, and this is not directly related to the 
thread.)
+1. I'm interested in the feature.

Recently, I encountered a case where it would be nice if
different wait events were output for each extension.

I tested a combination of two extensions, postgres_fdw and neon[1],
and they output the "Extension" wait event, but it wasn't immediately 
clear
which one was the bottleneck.

This is just a example and it probable be useful for other users. IMO, 
at least,
it's better to improve the specification that "Extension" wait event 
type has
only the "Extension" wait event.

[1] https://github.com/neondatabase/neon

Regards,

-- 
Masahiro Ikeda
NTT DATA CORPORATION



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tatsuo Ishii
Дата:
Сообщение: Re: Order changes in PG16 since ICU introduction
Следующее
От: "Hayato Kuroda (Fujitsu)"
Дата:
Сообщение: RE: [PoC] pg_upgrade: allow to upgrade publisher node