pg.ddx.io  pgsql-hackers@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Drouvot, Bertrand <bertranddrouvot.pg@gmail.com>
To: Michael Paquier <michael@paquier.xyz>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Andres Freund <andres@anarazel.de>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: Introduce WAIT_EVENT_EXTENSION and WAIT_EVENT_BUFFER_PIN
Date: Fri, 19 May 2023 09:48:10 +0200
Message-ID: <81290a48-b25c-22a5-31a6-3feff5864fe3@gmail.com> (raw)
In-Reply-To: <ZGaocGfirEt6OXNP@paquier.xyz>
References: <c6f35117-4b20-4c78-1df5-d3056010dcf5@gmail.com>
	<20230515182956.5lavflljhpgpokxc@awork3.anarazel.de>
	<ZGKynuIpQp1G8Bec@paquier.xyz>
	<20230516001716.iy7no2q77vwdt5w2@awork3.anarazel.de>
	<ZGLQnikZoxsqj2dl@paquier.xyz>
	<20230516010102.jwmsuaoynz6zfqmn@awork3.anarazel.de>
	<ZGMRMrrz02v8MGTE@paquier.xyz>
	<CA+TgmobtMj42OoAqETwhmiNU3k9LB+MiZhK+qdKg4Jh3Dq-Dag@mail.gmail.com>
	<20230517233832.si5zpq3qnxmx3swb@awork3.anarazel.de>
	<CA+TgmoaYTd3YN3N3vtXi+X63ePOzAdiKfVYX-BROtpWSdF-Auw@mail.gmail.com>
	<ZGaocGfirEt6OXNP@paquier.xyz>

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





view thread (25+ messages)  latest in thread

Message-ID: <81290a48-b25c-22a5-31a6-3feff5864fe3@gmail.com>
Permalink:  ../81290a48-b25c-22a5-31a6-3feff5864fe3@gmail.com/
Also on:    postgresql.org/message-id/81290a48-b25c-22a5-31a6-3feff5864fe3@gmail.com

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-hackers@postgresql.org
  Cc: bertranddrouvot.pg@gmail.com, michael@paquier.xyz, robertmhaas@gmail.com, andres@anarazel.de, pgsql-hackers@lists.postgresql.org
  Subject: Re: Introduce WAIT_EVENT_EXTENSION and WAIT_EVENT_BUFFER_PIN
  In-Reply-To: <81290a48-b25c-22a5-31a6-3feff5864fe3@gmail.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox