Re: per backend WAL statistics
Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
Hi, On Tue, Feb 18, 2025 at 08:34:32AM +0900, Michael Paquier wrote: > On Mon, Feb 17, 2025 at 03:14:59PM +0000, Bertrand Drouvot wrote: > > PFA the whole picture. 0001 is implementing the fields removal in pg_stat_wal > > (and also PendingWalStats). I think that's ok given the backend's type for which > > pgstat_tracks_io_bktype() returns false. But now you make me doubt about 0001. > > Double-checking the code now and my doubts are wrong. Thanks for double checking. > I think that I would vote for a removal of the fields from pg_stat_wal > rather than a replacement in pg_stat_wal, for the following reasons: > - pg_stat_stat.wal_write is the same value as "select sum(writes) > from pg_stat_io where object = 'wal' and context = 'normal'" as these > are incremented in XLogWrite(). > - Same argument about pg_stat_wal.wal_write_time with > pg_stat_io.write_time. > - issue_xlog_fsync() tells that pg_stat_wal.wal_sync_time and > sum(pg_stat_io.fsync_time) under object=wal and context=normal are the > same values. > - Same argument with the fsync counters pg_stat_wal.wal_sync and > pg_stat_io.fsyncs. > - Encourage monitoring pull to move to pg_stat_io, where there is much > more context and granularity of the stats data. Agree with all of the above + pgstat_tracks_io_bktype() returns false for backend's that do not generate WAL (so that we don't lose WAL information in pg_stat_io). > Regarding the GUC track_wal_io_timing, my take is that we'll live > better if we just let it go. It loses its meaning once pg_stat_wal > does not track the write and sync timings. Yeah, done that way in the dedicated thread ([1]). > > Anyway, it's probably better to move the 0001 discussion to a dedicated thread, > > thoughts? > > Yes. And we cannot really move forward with what we have here without > deciding about this part. The simplifications I can read from > v7-0002~v7-0004 are really nice. These make the implementation of WAL > stats at backend-level really simpler to think about. yup. > The doc additions of v7-0001 about the description of what the 'wal' > object does in pg_stat_io are actually worth a change of their own? > We already track them in pg_stat_io. Agree, done that way in the dedicated thread ([1]). [1]: https://www.postgresql.org/message-id/flat/Z7RkQ0EfYaqqjgz/%40ip-10-97-1-34.eu-west-3.compute.internal Regards, -- Bertrand Drouvot PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services: https://aws.amazon.com
Commits
-
Fix use-after-free in pgstat_fetch_stat_backend_by_pid()
- 3191a593d6de 18.0 landed
-
Remove initialization from PendingBackendStats
- f554a95379a9 18.0 landed
-
Add WAL data to backend statistics
- 76def4cdd7c2 18.0 landed
-
Improve check for detection of pending data in backend statistics
- 9a8dd2c5a6d9 18.0 landed
-
Fix some gaps in pg_stat_io with WAL receiver and WAL summarizer
- f4694e0f35b2 18.0 landed
-
Handle auxiliary processes in SQL functions of backend statistics
- 3f1db99bfabb 18.0 landed
-
Invent pgstat_fetch_stat_backend_by_pid()
- c2a50ac678eb 18.0 landed
-
Refactor code of pg_stat_get_wal() building result tuple
- 495864a4cf16 18.0 landed
-
Adding new PgStat_WalCounters structure in pgstat.h
- 0e42d31b0b22 18.0 landed
-
Remove pgstat_flush_wal()
- d7cbeaf261da 18.0 landed
-
Refactor some code related to backend statistics
- 2c14037bb57c 18.0 landed
-
Add backend-level statistics to pgstats
- 9aea73fc61d4 18.0 cited