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 1ph09F-0000uu-B8 for pgsql-hackers@arkaria.postgresql.org; Tue, 28 Mar 2023 03:37:25 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1ph08F-0001xE-0y for pgsql-hackers@arkaria.postgresql.org; Tue, 28 Mar 2023 03:36:23 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1ph08E-0001vr-Bn for pgsql-hackers@lists.postgresql.org; Tue, 28 Mar 2023 03:36:22 +0000 Received: from mail-pl1-x632.google.com ([2607:f8b0:4864:20::632]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1ph08B-0005bn-54 for pgsql-hackers@lists.postgresql.org; Tue, 28 Mar 2023 03:36:21 +0000 Received: by mail-pl1-x632.google.com with SMTP id k2so10393793pll.8 for ; Mon, 27 Mar 2023 20:36:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1679974578; h=content-transfer-encoding:mime-version:user-agent:references :in-reply-to:from:subject:cc:to:message-id:date:from:to:cc:subject :date:message-id:reply-to; bh=wM7QUBbVg+qXY9R9FW2+/6scxuHlMX4cRWuhybWPcPM=; b=b3AwxidaDLMypd9NdU17oYgSQvWd7j+ANKqimQbUyPDzun9Qn2ZzZqyg9try9YpX3G 1TvkERn4zIgerMVeXLR35EinjpPnD0wuR7OxcygZMDGCw3F3T0nuv/Rz1Ns/oUvNaLwu yaFw0+zXiNS7jWStO95twnaLcGUyRpv/jUzohiE4j09Vr1BEm/dr8kJVY6nevbNr8Ae8 /nHkEzWnJ7rMr1cICiBUhbDBr7jrgT1Upoh44/+LMJg9EeiaTYyizHNetkNe93oXNG8v 2EUi3XW5//ayDUyu7owb+FVS6Ry0p1WVi7K1689HIqFlRi3Wu6qRhx/CiL5cDrlJ7iHG a/Uw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1679974578; h=content-transfer-encoding:mime-version:user-agent:references :in-reply-to:from:subject:cc:to:message-id:date:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=wM7QUBbVg+qXY9R9FW2+/6scxuHlMX4cRWuhybWPcPM=; b=CQ36oGuuNWzhdec1Q6H6gz2hZyvuzbWatB4ijsj+n5qZiBYjbvhNc1ZsZaZa6Mb7Th HslwMwXtajlo4Fhj85qnEpf0zf0EdbGXNFIh4HkqaznOIjOEG23os8MeqldIWWaz84f7 I897dcf1jVm3tV5Ehk5DrnX4yw+yWwEbZ1pHW1EO+5qtR1ZC8X2kZ/9Q1b7Dfj4bkXoR meTA35Q9EhgaVCm/frxLynTsJJ5mXZ6lNZGDw8RRo4kG3aoUKoJCAa1LUbOfA6azmmnP +hMb4tbagjfd8FUv5WHBIeYZpZlBAUiGPMwrtWolYg/jvoPE7p3ZASgGVeHjh3Wqgg9C PjDA== X-Gm-Message-State: AAQBX9dHHUXVAxSNReSCT6YBKEI/a2NjaA/uT9cAnK8AnWZKu6abBsfg lySwmZcmZ7447TJORpm3bYA= X-Google-Smtp-Source: AKy350ZfX4zbBLH0x8bG2PS/hMJHe29JC6k0D256eYgSwCczFy4VElTKa71/LZiau7uvKuOBOwXzjw== X-Received: by 2002:a17:902:e543:b0:19e:665b:2514 with SMTP id n3-20020a170902e54300b0019e665b2514mr16287283plf.43.1679974578141; Mon, 27 Mar 2023 20:36:18 -0700 (PDT) Received: from localhost (KD036014041111.ppp-bb.dion.ne.jp. [36.14.41.111]) by smtp.gmail.com with ESMTPSA id b17-20020a631b51000000b004e28be19d1csm18801105pgm.32.2023.03.27.20.36.16 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256); Mon, 27 Mar 2023 20:36:17 -0700 (PDT) Date: Tue, 28 Mar 2023 12:36:15 +0900 (JST) Message-Id: <20230328.123615.1049160234680207474.horikyota.ntt@gmail.com> To: michael@paquier.xyz Cc: melanieplageman@gmail.com, bertranddrouvot.pg@gmail.com, andres@anarazel.de, pgsql-hackers@lists.postgresql.org Subject: Re: Reconcile stats in find_tabstat_entry() and get rid of PgStat_BackendFunctionEntry From: Kyotaro Horiguchi In-Reply-To: References: User-Agent: Mew version 6.8 on Emacs 26.1 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk At Tue, 28 Mar 2023 07:38:25 +0900, Michael Paquier wrote in > On Mon, Mar 27, 2023 at 10:24:46AM -0400, Melanie Plageman wrote: > > I do like/prefer "block read requests" and > > "blocks requested found in cache" > > Though, now I fear my initial complaint may have been a bit pedantic. > > That's fine. Let's ask for extra opinions, then. > > So, have others an opinion to share here? I do not have a strong preference for the wording, but consistency is important. IMHO simply swapping out a few words won't really improve things. I found that commit ddfc2d9a37 removed the descriptions for pg_stat_get_blocks_fetched and pg_stat_get_blocks_hit. Right before that commit, monitoring.sgml had these lines: - pg_stat_get_blocks_fetched minus - pg_stat_get_blocks_hit gives the number of kernel - read() calls issued for the table, index, or - database; the number of actual physical reads is usually - lower due to kernel-level buffering. The *_blks_read - statistics columns use this subtraction, i.e., fetched minus hit. The commit then added the following sentence to the description for pg_statio_all_tables.heap_blks_read. > Number of disk blocks read from this table. > This value can also be returned by directly calling > the pg_stat_get_blocks_fetched and > pg_stat_get_blocks_hit functions and > subtracting the results. Later, in 5f2b089387 it twas revised as: + Number of disk blocks read in this database This revision lost the explantion regarding the relationship among fetch, hit and read, as it became hidden in the views' definitions. As the result, in the current state, it doesn't make sense to just add a description for pg_stat_get_xact_blocks_fetched(). The confusion stems from the inconsistency between the views and underlying functions related to block reads and hits. If we add descriptions for the two functions, we should also explain their relationship. Otherwise, it might be better to add the functions pg_stat_*_blocks_read() instead. regards. -- Kyotaro Horiguchi NTT Open Source Software Center