Re: Show WAL write and fsync stats in pg_stat_io
Michael Paquier <michael@paquier.xyz>
From: Michael Paquier <michael@paquier.xyz>
To: Andres Freund <andres@anarazel.de>
Cc: Nazir Bilal Yavuz <byavuz81@gmail.com>, pgsql-hackers <pgsql-hackers@postgresql.org>, "bharath.rupireddyforpostgres@gmail.com"
<bharath.rupireddyforpostgres@gmail.com>
Date: 2023-11-08T00:52:16Z
Lists: pgsql-hackers
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Fix copy-paste error related to the autovacuum launcher in pgstat_io.c
- 17d8bba6dad1 18.0 landed
-
Move SQL tests of pg_stat_io for WAL data to recovery test 029_stats_restart
- 428fadb7e97e 18.0 landed
-
Add data for WAL in pg_stat_io and backend statistics
- a051e71e28a1 18.0 landed
-
Improve comment on top of pgstat_count_io_op_time()
- b998fedab74c 18.0 landed
-
Refactor pgstat_prepare_io_time() with an input argument instead of a GUC
- 3c9d9acae0bc 17.0 landed
On Tue, Nov 07, 2023 at 03:30:48PM -0800, Andres Freund wrote: > I strongly disagree. A significant part of the design of pg_stat_io was to > make it possible to collect multiple sources of IO in a single view, so that > sysadmins don't have to look in dozens of places to figure out what is causing > what kind of IO. Okay. Point taken. > We should over time collect all sources of IO in pg_stat_io. For some things > we might want to also have more detailed information in other views (e.g. it > doesn't make sense to track FPIs in pg_stat_io, but does make sense in > pg_stat_wal) - but that should be in addition, not instead of. Sure. I understand here that you mean the number of FPIs counted when a record is inserted, different from the path where we decide to write and/or flush WAL. The proposed patch seems to be a bit inconsistent regarding wal_sync_time, by the way. By the way, if the write/sync quantities and times begin to be tracked by pg_stat_io, I'd see a pretty good argument in removing the equivalent columns in pg_stat_wal. It looks like this would reduce the confusion related to the handling of PendingWalStats added in pgstat_io.c, for one. -- Michael