Re: Show WAL write and fsync stats in pg_stat_io

Michael Paquier <michael@paquier.xyz>

From: Michael Paquier <michael@paquier.xyz>
To: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
Cc: Nazir Bilal Yavuz <byavuz81@gmail.com>, 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-02-04T07:03:55Z
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

On Mon, Feb 03, 2025 at 10:37:54AM +0000, Bertrand Drouvot wrote:
> Based on those results the patch does not show a noticable impact when IO timing
> tracking is/are enabled.

I have spent a good portion of my day doing benchmarking with your
scenarios as much as Nazir's scenarios posted at [1], with
arch_sys_counter as clock source (I am not much into these settings)
on the host I have used.  And well, I am not seeing a difference
between the patch and HEAD when enabling the GUC track_io_timing.  I
do seem to see a difference when disabling the GUC in the order of
1~2% for the patch and HEAD.

> FYI, It’s also worth noticing that if hpet is set then it also affect negatively
> even if no timing tracking is set. It means that when track IO timing is/are
> enabled the perf regression seen above are not fully related to having then
> enabled but also (for a large part) to hpet vs tsc.

Oh, interesting.

[1]: https://postgr.es/m/CAN55FZ3rb1SPp_17R5nMq+tqLDa0Odb7CxJDsBtW6d4AZo1MGg@mail.gmail.com
--
Michael