Re: Introduce WAIT_EVENT_EXTENSION and WAIT_EVENT_BUFFER_PIN

Hi,

On 5/19/23 12:36 AM, Michael Paquier wrote:
> On Thu, May 18, 2023 at 12:28:20PM -0400, Robert Haas wrote:
>> I mean, I agree that it would probably be hard to measure any real
>> performance difference. But I'm not sure that's a good reason to add
>> cycles to a path where we don't really need to.
>
> Honestly, I am not sure that it's worth worrying about performance
> here,

Same feeling here and as those new functions will be used "only" from
pg_stat_get_activity() / pg_stat_get_backend_wait_event().

> or perhaps you know of some external stuff that could set the
> extension class type in a code path hot enough that it would matter.

And that would matter, only when making use of pg_stat_get_activity()
/ pg_stat_get_backend_wait_event() at the time the "extension is waiting"
on this wait event.

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.

Regards,

--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com