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 ZBuEPgVYzigWcldN@paquier.xyz
Whole thread Raw
In response to Re: Reconcile stats in find_tabstat_entry() and get rid of PgStat_BackendFunctionEntry  (Melanie Plageman <melanieplageman@gmail.com>)
Responses Re: Reconcile stats in find_tabstat_entry() and get rid of PgStat_BackendFunctionEntry
List pgsql-hackers
On Wed, Mar 22, 2023 at 02:21:12PM -0400, Melanie Plageman wrote:
> Apologies as I know this docs update has already been committed, but
> buffers fetched and blocks fetched both feel weird to me. If you have a
> cache hit, you don't end up really "fetching" anything at all (since
> pgstat_count_buffer_read() is called before ReadBuffer_common() and we
> don't know if it is a hit or miss yet). And, I would normally associate
> fetching with fetching a block into a buffer. It seems like this counter
> is really reflecting the number of buffers acquired or used.

Well, it is the number of times we've requested a block read, though
it may not actually be a read if the block was in the cache already.

> This isn't really the fault of this patch since that member was already
> called blocks_fetched.

The original documentation of these functions added by 46aa77c refers
to "block fetch requests" and "block requests found in cache", so that
would not be right either based on your opinion here.  If you find
"fetch" to be incorrect in this context, here is another idea:
- "block read requests" for blocks_fetched().
- "block read requested but actually found in cache" for blocks_hit().

All the system views care only about the difference between both
counters to count the number of physical reads really done.
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Improve logging when using Huge Pages
Next
From: Eske Rahn
Date:
Subject: Re: Options to rowwise persist result of stable/immutable function with RECORD result