Horton

Re: Show WAL write and fsync stats in pg_stat_io

Bertrand Drouvot <bertranddrouvot.pg@gmail.com>

View thread
From: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
To: Nazir Bilal Yavuz <byavuz81@gmail.com>
Cc: Michael Paquier <michael@paquier.xyz>, Melanie Plageman <melanieplageman@gmail.com>, Andres Freund <andres@anarazel.de>, pgsql-hackers <pgsql-hackers@postgresql.org>, "bharath.rupireddyforpostgres@gmail.com" <bharath.rupireddyforpostgres@gmail.com>, Thomas Munro <thomas.munro@gmail.com>
Date: 2025-01-29T14:37:45Z
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 →

  1. Fix copy-paste error related to the autovacuum launcher in pgstat_io.c

  2. Move SQL tests of pg_stat_io for WAL data to recovery test 029_stats_restart

  3. Add data for WAL in pg_stat_io and backend statistics

  4. Improve comment on top of pgstat_count_io_op_time()

  5. Refactor pgstat_prepare_io_time() with an input argument instead of a GUC

Hi,

On Wed, Jan 29, 2025 at 01:49:20PM +0300, Nazir Bilal Yavuz wrote:
> Sorry for replying late.

No problem at all!

> It turns out that the difference is expected.
> It is because pg_stat_wal.wal_bytes tracks the total amount of WAL
> generated, while pg_stat_io tracks the I/Os that are written to disk.

Yeah, I do agree it's expected: Indeed pg_stat_wal.wal_bytes somehow "focus"
on the wal records size while the pg_stat_io's unit is the wal_block_size. That
makes sense and "only" affects the "bytes" (the remaining common fields looks
consistent across the 2 views).

> It is explicitly said that pg_stat_io tracks I/O operations and
> pg_stat_wal.wal_bytes tracks total amount of WAL generated in bytes. I
> think this is clear enough. Do you think we still need additional
> explanation?

I think that would not hurt to add a comment mentioning that the "bytes" are
expected to differ given the fact that the IO unit is the wal_block_size. But,
that said, I don't have a strong opinion on it, just a nice to have IMHO.

Regards,

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