Horton

Re: Support to define custom wait events for extensions

Masahiro Ikeda <ikedamsh@oss.nttdata.com>

View thread View on postgr.es
From: Masahiro Ikeda <ikedamsh@oss.nttdata.com>
To: "Drouvot, Bertrand" <bertranddrouvot.pg@gmail.com>
Cc: Michael Paquier <michael@paquier.xyz>, pgsql-hackers@lists.postgresql.org
Date: 2023-06-16T02:17:37Z
Lists: pgsql-hackers 
On 2023-06-15 22:21, Drouvot, Bertrand wrote:
> Hi,
> 
> On 6/15/23 10:00 AM, Michael Paquier wrote:
>> On Thu, Jun 15, 2023 at 03:06:01PM +0900, Masahiro Ikeda wrote:
>>> Currently, only one PG_WAIT_EXTENSION event can be used as a
>>> wait event for extensions. Therefore, in environments with multiple
>>> extensions are installed, it could take time to identify which
>>> extension is the bottleneck.
>> 
>> Thanks for taking the time to implement a patch to do that.
> 
> +1 thanks for it!
> 
>> 
>>> I want to know your feedbacks. Please feel free to comment.
>> 
>> I think that's been cruelly missed.
> 
> Yeah, that would clearly help to diagnose which extension(s) is/are
> causing the waits (if any).
> 
> I did not look at the code yet (will do) but just wanted to chime in
> to support the idea.

Great! Thanks.

Regards,
-- 
Masahiro Ikeda
NTT DATA CORPORATION

Commits

  1. Change custom wait events to use dynamic shared hash tables

  2. Support custom wait events for wait event type "Extension"

  3. Add WAIT_EVENT_{CLASS,ID}_MASK in wait_event.c

  4. worker_spi: Switch to TAP tests

  5. Simplify some conditions related to [LW]Lock in generate-wait_event_types.pl