Re: Add statistics to pg_stat_wal view for wal related parameter tuning

From: Masahiro Ikeda <ikedamsh(at)oss(dot)nttdata(dot)com>
To: lchch1990(at)sina(dot)cn
Cc: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Add statistics to pg_stat_wal view for wal related parameter tuning
Date: 2020-10-22 01:34:28
Message-ID: ac8b1f5e589932254efe373e252e5dcb@oss.nttdata.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2020-10-21 15:54, lchch1990(at)sina(dot)cn wrote:
> I think it's really a more convenient way to collect wal usage
> information,
> with it we can query when I want. Several points on my side:

Thanks for your comments.

> 1. It will be nice If you provide a chance to reset the information in
> WalStats,
> so that we can reset it without restart the database.

I agree.

Now, pg_stat_wal supports reset all informantion in WalStats
using pg_stat_reset_shared('wal') function.

Isn't it enough?

> 2. I think 'wal_write_backend' is mean wal write times happen in
> backends. The describe in document is not so clear, suggest rewrite
> it.

OK, I'll rewrite to "Total number of times backends write WAL data to
the disk".

> 3. I do not think it's a correct describe in document for
> 'wal_buffers_full'.

Where should I rewrite the description? If my understanding is not
correct, please let me know.

> 4. Quite strange to collect twice in XLogInsertRecord() for
> xl_tot_len,
> m_wal_records, m_wal_fpi.

Yes, Amit-san pointed me that too.
I'll remove them from pg_stat_wal since pg_stat_statements and vacuum
log
already shows the related statistics and there is a comment it's enough.

Anyway, if you need to the accumulated above statistics in pg_stat_wal,
please let me know.

> 5. I notice some code in issue_xlog_fsync() function to collect sync
> info,
> a standby may call the issue_xlog_fsync() too, which do not want to
> to collect this info. I think this need some change avoid run by
> standby
> side.

Thanks, I will fix it.

Regards,
--
Masahiro Ikeda
NTT DATA CORPORATION

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message tsunakawa.takay@fujitsu.com 2020-10-22 01:35:38 RE: [Patch] Optimize dropping of relation buffers using dlist
Previous Message tsunakawa.takay@fujitsu.com 2020-10-22 01:33:31 RE: [Patch] Optimize dropping of relation buffers using dlist