public inbox for [email protected]  

help / color / mirror / Atom feed

From: Michael Paquier <[email protected]>
To: Bertrand Drouvot <[email protected]>
Cc: Nazir Bilal Yavuz <[email protected]>
Cc: Alvaro Herrera <[email protected]>
Cc: Kyotaro Horiguchi <[email protected]>
Cc: [email protected]
Subject: Re: per backend I/O statistics
Date: Mon, 25 Nov 2024 10:06:44 +0900
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>

On Fri, Nov 22, 2024 at 07:49:58AM +0000, Bertrand Drouvot wrote:
> On Fri, Nov 22, 2024 at 10:36:29AM +0900, Michael Paquier wrote:
>> Hmm.  created_entry only matters for pgstat_init_function_usage().
>> All the other callers of pgstat_prep_pending_entry() pass a NULL
>> value. 
> 
> I meant to say all the calls that passe "create" as true in pgstat_get_entry_ref().

Ah, OK, I think that I see your point here.

I am wondering how much this would matter as well for custom stats,
but we're not there yet without at least one release out and folks try
new things with these APIs and variable-numbered kinds.  Allowing
pgstat_prep_pending_entry() to return NULL even if "create" is true
may be a good thing, at the end, because that's the only way I can see
based on the current APIs where we could say "Sorry, but the stats
have not been loaded yet, so you cannot try to do anything related to
the dshash".

From my view having a kind of barrier would be cleaner in the long
run, but it's true that it may not be mandatory, as well.  pg_stat_io
is currently OK to be called because the stats are loaded for
auxiliary processes because it uses fixed-numbered stats in shmem.
And it means we already have early calls that add stats getting
overwritten once the stats are loaded from the on-disk file (Am I
getting this part right?).

Anyway, do we really require that for the sake of this thread?  We
know that there's only one of each auxiliary process at a time, and
they keep a footprint in pg_stat_io already.  So we could just limit
outselves to live database backends, WAL senders and autovacuum
workers, everything that's not auxiliary and spawned on request?
--
Michael


Attachments:

  [application/pgp-signature] signature.asc (833B, ../[email protected]/2-signature.asc)
  download

view thread (31+ messages)

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: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
  Subject: Re: per backend I/O statistics
  In-Reply-To: <[email protected]>

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

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