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-25T07:18:54Z
Lists: pgsql-hackers 
On Mon, Nov 25, 2024 at 07:12:56AM +0000, Bertrand Drouvot wrote:
> Not sure here, could custom stats start incrementing before the database system
> is ready to accept connections?

In theory, that could be possible.  Like pg_stat_io currently, I am
ready to assume that it likely won't matter much.

> The only cons that I can see is that we will not be able to merge the flush cb
> but I don't think that's a blocker (the flush are done in shared memory so the
> impact on performance should not be that much of an issue).

The backend and I/O stats could begin diverging as a result of a new
implementation detail, and the performance of the flushes don't worry
me knowing at which frequency they happen on a live system.
--
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