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
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 |