Re: Reconcile stats in find_tabstat_entry() and get rid of PgStat_BackendFunctionEntry

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Melanie Plageman <melanieplageman(at)gmail(dot)com>
Cc: "Drouvot, Bertrand" <bertranddrouvot(dot)pg(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Reconcile stats in find_tabstat_entry() and get rid of PgStat_BackendFunctionEntry
Date: 2023-03-22 22:42:06
Message-ID: ZBuEPgVYzigWcldN@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Eske Rahn 2023-03-22 23:32:42 Re: Options to rowwise persist result of stable/immutable function with RECORD result
Previous Message Michael Paquier 2023-03-22 22:23:28 Re: Improve logging when using Huge Pages