Horton

Re: per backend I/O statistics

Michael Paquier <michael@paquier.xyz>

View thread View on postgr.es
From: Michael Paquier <michael@paquier.xyz>
To: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
Cc: Nazir Bilal Yavuz <byavuz81@gmail.com>, Alvaro Herrera <alvherre@alvh.no-ip.org>, Kyotaro Horiguchi <horikyota.ntt@gmail.com>, pgsql-hackers@lists.postgresql.org
Date: 2024-11-22T01:36:29Z
Lists: pgsql-hackers 
On Thu, Nov 21, 2024 at 05:23:42PM +0000, Bertrand Drouvot wrote:
> So, given that:
> 
> - the end result would be the same
> - the code changes would be non negligible (unless we have a better idea than
> pgstat_get_entry_ref() returning a NULL value).

Hmm.  created_entry only matters for pgstat_init_function_usage().
All the other callers of pgstat_prep_pending_entry() pass a NULL
value.  This makes me wonder if there is an argument for reworking a
bit that.  There's a fat comment about the reason why, still, that
would make the get interface for variable-numbered stats a lot
leaner..  Not sure what to think about that.
--
Michael

Commits

  1. Rework handling of pending data for backend statistics

  2. Rename some pgstats callbacks related to flush of entries

  3. Relax regression test for fsync check of backend-level stats

  4. Add backend-level statistics to pgstats

  5. Extract logic filling pg_stat_get_io()'s tuplestore into its own routine

  6. Tweak some comments related to variable-numbered stats in pgstat.c