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 1kfeuf-00036i-QE for pgsql-hackers@arkaria.postgresql.org; Thu, 19 Nov 2020 08:03:29 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1kfeue-0002MC-Ov for pgsql-hackers@arkaria.postgresql.org; Thu, 19 Nov 2020 08:03:28 +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 1kfeue-0002M4-Hx for pgsql-hackers@lists.postgresql.org; Thu, 19 Nov 2020 08:03:28 +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 1kfeuc-0006wH-73 for pgsql-hackers@postgresql.org; Thu, 19 Nov 2020 08:03:28 +0000 Received: from oss.nttdata.com (localhost [127.0.0.1]) by oss.nttdata.com (Postfix) with ESMTP id DF9046235E; Thu, 19 Nov 2020 17:03:20 +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: Thu, 19 Nov 2020 17:03:20 +0900 From: Masahiro Ikeda To: lchch1990@sina.cn Cc: Fujii Masao , Amit Kapila , pgsql-hackers Subject: Re: Add statistics to pg_stat_wal view for wal related parameter tuning In-Reply-To: <2020111711533714942211@sina.cn> References: <35ef960128b90bfae3b3fdf60a3a860f@oss.nttdata.com>, , <06bc2d405b086a72fb14657de9befae8@oss.nttdata.com>, <2020102114544806663477@sina.cn>, , <2020111311322320943423@sina.cn>, <3599412d5f3eee44e3658e81d3790f6a@oss.nttdata.com>, <2020111711533714942211@sina.cn> Message-ID: <8cce3af13eae4116a98fd29eaa2d9e54@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-17 12:53, lchch1990@sina.cn wrote: >>> 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' >> Or what about the following? >> Total number of times WAL data was written to the disk, to claim the > buffer page to insert new >> WAL data when the WAL buffers got filled up with unwritten WAL data. > As my understand we can not say 'full' because every wal page mapped a > special wal buffer slot. > When a wal page need to be write, but the buffer slot was occupied by > other wal page. It need to > wait the wal buffer slot released. So i think we should say it > 'occupied' not 'full'. > > Maybe: > Total number of times WAL data was written to the disk, to claim the > buffer page to insert new > WAL data when the special WAL buffer occupied by other page. OK, I will change the above sentence since there are some sentences like "space occupied by", "disk blocks occupied", and so on in the documents. Do we need to change the column name from "wal_buffers_full" to another name like "wal_buffers_all_occupied"? Regards -- Masahiro Ikeda NTT DATA CORPORATION