From: | Masahiro Ikeda <ikedamsh(at)oss(dot)nttdata(dot)com> |
---|---|
To: | kuroda(dot)hayato(at)fujitsu(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 12:14:28 |
Message-ID: | 745b2bca8ea79d562d03f339ca193f9e@oss.nttdata.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2021-01-22 11:54, kuroda(dot)hayato(at)fujitsu(dot)com wrote:
> 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.
Kuroda-san, Thanks for your comments.
Although I thought that the performance impact may be bigger in standby
servers
because WALReceiver didn't use wal buffers, it's no need to be
considered.
I agreed that if track_wal_io_timing is turned on, the primary server's
performance degradation occurs too.
I will make rebased and modified.
Regards,
--
Masahiro Ikeda
NTT DATA CORPORATION
From | Date | Subject | |
---|---|---|---|
Next Message | Heikki Linnakangas | 2021-01-22 12:21:45 | Re: Online checksums patch - once again |
Previous Message | Magnus Hagander | 2021-01-22 11:56:10 | mkid reference |