Re: Reconcile stats in find_tabstat_entry() and get rid of PgStat_BackendFunctionEntry - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: Reconcile stats in find_tabstat_entry() and get rid of PgStat_BackendFunctionEntry
Date
Msg-id ZCJ53/VggExTFoO+@paquier.xyz
Whole thread Raw
In response to Re: Reconcile stats in find_tabstat_entry() and get rid of PgStat_BackendFunctionEntry  (Kyotaro Horiguchi <horikyota.ntt@gmail.com>)
Responses Re: Reconcile stats in find_tabstat_entry() and get rid of PgStat_BackendFunctionEntry  ("Drouvot, Bertrand" <bertranddrouvot.pg@gmail.com>)
List pgsql-hackers
On Tue, Mar 28, 2023 at 12:36:15PM +0900, Kyotaro Horiguchi wrote:
> 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:
>
> -     <function>pg_stat_get_blocks_fetched</function> minus
> -     <function>pg_stat_get_blocks_hit</function> gives the number of kernel
> -     <function>read()</> calls issued for the table, index, or
> -     database; the number of actual physical reads is usually
> -     lower due to kernel-level buffering.  The <literal>*_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.
>
> Later, in 5f2b089387 it twas revised as:
> +     <entry>Number of disk blocks read in this database</entry>

Yeah, maybe adding something like that at the bottom of the table for
stat functions, telling that the difference is the number of read()
calls, may help.  Perhaps also adding a mention that these are used in
none of the existing system views..

> 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.

I am not sure that we really need to get down to that as this holds
the same meaning as the current system views showing read as the
difference between fetched and hit.
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: "Drouvot, Bertrand"
Date:
Subject: Re: Generate pg_stat_get_xact*() functions with Macros
Next
From: Jeff Davis
Date:
Subject: Re: running logical replication as the subscription owner