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

From: Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>
To: michael(at)paquier(dot)xyz
Cc: bertranddrouvot(dot)pg(at)gmail(dot)com, melanieplageman(at)gmail(dot)com, andres(at)anarazel(dot)de, 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-28 08:43:26
Message-ID: 20230328.174326.1226788895063455868.horikyota.ntt@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

At Tue, 28 Mar 2023 15:16:36 +0900, Michael Paquier <michael(at)paquier(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jelte Fennema 2023-03-28 09:15:28 Re: running logical replication as the subscription owner
Previous Message Dmitry Koval 2023-03-28 08:28:05 Re: Add SPLIT PARTITION/MERGE PARTITIONS commands