pg.ddx.io  pgsql-hackers@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Masahiro Ikeda <ikedamsh@oss.nttdata.com>
To: lchch1990@sina.cn
Cc: Amit Kapila <amit.kapila16@gmail.com>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>
Subject: Re: Add statistics to pg_stat_wal view for wal related parameter tuning
Date: Thu, 22 Oct 2020 10:34:28 +0900
Message-ID: <ac8b1f5e589932254efe373e252e5dcb@oss.nttdata.com> (raw)
In-Reply-To: <2020102114544806663477@sina.cn>
References: <35ef960128b90bfae3b3fdf60a3a860f@oss.nttdata.com>
	<CAA4eK1JbbP-QmZWiXwK+H-ZauJCGR6vbAVoGdyx_TTxRPuXzhQ@mail.gmail.com>
	<06bc2d405b086a72fb14657de9befae8@oss.nttdata.com>
	<2020102114544806663477@sina.cn>

On 2020-10-21 15:54, lchch1990@sina.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





view thread (33+ messages)  latest in thread

Message-ID: <ac8b1f5e589932254efe373e252e5dcb@oss.nttdata.com>
Permalink:  ../ac8b1f5e589932254efe373e252e5dcb@oss.nttdata.com/
Also on:    postgresql.org/message-id/ac8b1f5e589932254efe373e252e5dcb@oss.nttdata.com

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-hackers@postgresql.org
  Cc: ikedamsh@oss.nttdata.com, lchch1990@sina.cn, amit.kapila16@gmail.com
  Subject: Re: Add statistics to pg_stat_wal view for wal related parameter tuning
  In-Reply-To: <ac8b1f5e589932254efe373e252e5dcb@oss.nttdata.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox