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

From Kyotaro Horiguchi
Subject Re: Reconcile stats in find_tabstat_entry() and get rid of PgStat_BackendFunctionEntry
Date
Msg-id 20230328.174326.1226788895063455868.horikyota.ntt@gmail.com
Whole thread Raw
In response to Re: Reconcile stats in find_tabstat_entry() and get rid of PgStat_BackendFunctionEntry  (Michael Paquier <michael@paquier.xyz>)
Responses Re: Reconcile stats in find_tabstat_entry() and get rid of PgStat_BackendFunctionEntry  (Michael Paquier <michael@paquier.xyz>)
List pgsql-hackers
At Tue, 28 Mar 2023 15:16:36 +0900, Michael Paquier <michael@paquier.xyz> wrote in 
> On Tue, Mar 28, 2023 at 07:49:45AM +0200, Drouvot, Bertrand wrote:
> > What about something like?
> > 
> > for pg_stat_get_xact_blocks_fetched(): "block read requests for table or index, in the current
> > transaction. This number minus pg_stat_get_xact_blocks_hit() gives the number of kernel
> > read() calls."
> > 
> > pg_stat_get_xact_blocks_hit(): "block read requests for table or index, in the current
> > transaction, found in cache (not triggering kernel read() calls)".
> 
> Something among these lines within the table would be also OK by me.
> Horiguchi-san or Melanie-san, perhaps you have counter-proposals?

No. Fine by me, except that "block read requests" seems to suggest
kernel read() calls, maybe because it's not clear whether "block"
refers to our buffer blocks or file blocks to me.. If it is generally
clear, I'm fine with the proposal.

regards.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center



pgsql-hackers by date:

Previous
From: Dmitry Koval
Date:
Subject: Re: Add SPLIT PARTITION/MERGE PARTITIONS commands
Next
From: Jelte Fennema
Date:
Subject: Re: running logical replication as the subscription owner