Re: per backend WAL statistics
Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
Hi, On Thu, Jan 23, 2025 at 05:05:30PM +0900, Michael Paquier wrote: > On Tue, Jan 21, 2025 at 07:19:55AM +0000, Bertrand Drouvot wrote: > > PFA v6 that now relies on the new PendingBackendStats variable introduced in > > 4feba03d8b9. > > > > Remark: I moved PendingBackendStats back to pgstat.h because I think that the > > "simple" pending stats increment that we are adding in xlog.c are not worth > > an extra function call overhead (while it made more sense for the more complex IO > > stats handling). So PendingBackendStats is now visible to the outside world like > > PendingWalStats and friends. > > You are re-doing here a pattern I was trying to avoid so as we don't > copy-paste more checks based on pgstat_tracks_backend_bktype more than > necessary. I'm not sure I get it. pgstat_tracks_backend_bktype() is also called in pgstat_count_backend_io_op() and pgstat_count_backend_io_op_time(). What issue do you see with the extra calls part of this patch? > I am wondering if we should think harder about the > interface used to register WAL stats, and make it more consistent with > the way pg_stat_io is handled, avoiding the hardcoded attribute > numbers if we have an enum to control which field to update in some > input routine. Not sure as WAL stats just tracks a single dimension unlike IO stats which track both IOObject and IOContext. What would be the benefit(s)? > As we have only five counters in PgStat_PendingWalStats, the result > you have is not that invasive, true. And only one dimension. > Are you sure that the interactions between pgWalUsage, prevWalUsage > and prevBackendWalUsage are correct? I think so and according to my testing I can see WalUsage values that correlate nicely between pg_stat_wal() and pg_stat_get_backend_wal(). > As far I got it from a code > read, prevWalUsage, prevBackendWalUsage and their local trackings in > pgstat_backend.c and pgstat_wal.c rely on instrument.c as the primary > source, as pgWalUsage can never be reset. Is that right? yeah, IIUC pgWalUsage acts as the primary source that both prevWalUsage and prevBackendWalUsage diff against to calculate incremental stats. 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