Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1keakG-0001Ga-T4 for pgsql-hackers@arkaria.postgresql.org; Mon, 16 Nov 2020 09:24:20 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1keakF-0006yl-LX for pgsql-hackers@arkaria.postgresql.org; Mon, 16 Nov 2020 09:24:19 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1keakF-0006yN-EX for pgsql-hackers@lists.postgresql.org; Mon, 16 Nov 2020 09:24:19 +0000 Received: from oss.nttdata.com ([49.212.34.109]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1keakC-00052Z-0z for pgsql-hackers@postgresql.org; Mon, 16 Nov 2020 09:24:17 +0000 Received: from oss.nttdata.com (localhost [127.0.0.1]) by oss.nttdata.com (Postfix) with ESMTP id 1B1286151A; Mon, 16 Nov 2020 18:24:10 +0900 (JST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.102.3 at oss.nttdata.com MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Mon, 16 Nov 2020 18:24:10 +0900 From: Masahiro Ikeda To: lchch1990@sina.cn Cc: Amit Kapila , pgsql-hackers Subject: Re: Add statistics to pg_stat_wal view for wal related parameter tuning In-Reply-To: <2020111311322320943423@sina.cn> References: <35ef960128b90bfae3b3fdf60a3a860f@oss.nttdata.com>, , <06bc2d405b086a72fb14657de9befae8@oss.nttdata.com>, <2020102114544806663477@sina.cn>, <2020111311322320943423@sina.cn> Message-ID: <3599412d5f3eee44e3658e81d3790f6a@oss.nttdata.com> X-Sender: ikedamsh@oss.nttdata.com User-Agent: Roundcube Webmail/1.1.9 List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On 2020-11-13 12:32, lchch1990@sina.cn wrote: >> Now, pg_stat_wal supports reset all informantion in WalStats >> using pg_stat_reset_shared('wal') function. >> Isn't it enough? > Yes it ok, sorry I miss this infomation. OK. >>> 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. > Sorry I have not described it clearly, because I can not understand > the meaning of this > column after I read the describe in document. > And now I read the source code of walwrite and found the place where > 'wal_buffers_full' > added is for a backend to wait a wal buffer which is occupied by other > wal page, so the > backend flush the old page in the wal buffer(after wait it can). > So i think the origin decribe in document is not so in point, we can > describe it such as > 'Total number of times WAL data written to the disk because a backend > yelled a wal buffer > for an advanced wal page. > > Sorry if my understand is wrong. Thanks for your comments. You're understanding is almost the same as mine. It describes when not only backends but also other backgrounds initialize a new wal page, wal buffer's space is already used and there is no space. > 'Total number of times WAL data written to the disk because a backend > yelled a wal buffer for an advanced wal page' Thanks for your suggestion. I wondered that users may confuse about how to use "wal_buffers_full" and how to tune parameters. I thought the reason which wal buffer has no space is important for users to tune the wal_buffers parameter. How about the following comments? 'Total number of times WAL data was written to the disk because WAL buffers got full when to initialize a new WAL page' Regards, -- Masahiro Ikeda NTT DATA CORPORATION