Re: per backend I/O statistics

Hi,

On Mon, Nov 25, 2024 at 04:18:54PM +0900, Michael Paquier wrote:
> 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.

Yeah right, agree.

> > 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.

Same here.

Please find attached v6 that enables per-backend I/O stats for the
B_AUTOVAC_WORKER, B_BACKEND, B_BG_WORKER, B_STANDALONE_BACKEND, B_SLOTSYNC_WORKER
and B_WAL_SENDER backend types.

It also takes care of most of the comments that you have made in [1], meaning
that it:

- removes the backend type from PgStat_Backend and look for the backend type
at "display" time.
- creates PgStat_BackendPendingIO and PgStat_PendingIO now refers to it (I 
used PgStat_BackendPendingIO and not PgStat_BackendPending because this is what
it is after all).
- adds the missing comment related to the PID in the doc.
- merges 0004 with 0001 (so that pg_stat_get_backend_io() is now part of 0001).
- creates its own pgstat_backend.c file.

=== Remarks

R1: as compared to v5, v6 removes the per-backend I/O stats reset from 
pg_stat_reset_shared(). I think it makes more sense that way, since we are
adding pg_stat_reset_single_backend_io_counters(). The per-backend I/O stats
behaves then as the subscription stats as far the reset is concerned.
 
R2: as we can't merge the flush cb anymore, only the patches related to
the stats_fetch_consistency/'snapshot' are missing in v6 (as compared to v5).
I propose to re-submit them, re-start the discussion once 0001 goes in.

[1]: https://www.postgresql.org/message-id/ZzWZV9LdyZ9aFSWs%40paquier.xyz

Regards,

-- 
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com