RE: About to add WAL write/fsync statistics to pg_stat_wal view

From: "kuroda(dot)hayato(at)fujitsu(dot)com" <kuroda(dot)hayato(at)fujitsu(dot)com>
To: 'Masahiro Ikeda' <ikedamsh(at)oss(dot)nttdata(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: RE: About to add WAL write/fsync statistics to pg_stat_wal view
Date: 2021-01-22 02:54:17
Message-ID: TYAPR01MB3168FD6040FFA8CA1D9E3E8BF5A00@TYAPR01MB3168.jpnprd01.prod.outlook.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Dear Ikeda-san,

This patch cannot be applied to the HEAD, but anyway I put a comment.

```
+ /*
+ * Measure i/o timing to fsync WAL data.
+ *
+ * The wal receiver skip to collect it to avoid performance degradation of standy servers.
+ * If sync_method doesn't have its fsync method, to skip too.
+ */
+ if (!AmWalReceiverProcess() && track_wal_io_timing && fsyncMethodCalled())
+ INSTR_TIME_SET_CURRENT(start);
```

I think m_wal_sync_time should be collected even if the process is WalRecevier.
Because all wal_fsync should be recorded, and
some performance issues have been aleady occurred if track_wal_io_timing is turned on.
I think it's strange only to take care of the walrecevier case.

Best Regards,
Hayato Kuroda
FUJITSU LIMITED

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Greg Nancarrow 2021-01-22 02:58:50 Re: Parallel INSERT (INTO ... SELECT ...)
Previous Message Justin Pryzby 2021-01-22 02:48:11 Re: pglz compression performance, take two