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

Поиск
Список
Период
Сортировка
От Kyotaro Horiguchi
Тема Re: Reconcile stats in find_tabstat_entry() and get rid of PgStat_BackendFunctionEntry
Дата
Msg-id 20230328.174326.1226788895063455868.horikyota.ntt@gmail.com
обсуждение исходный текст
Ответ на Re: Reconcile stats in find_tabstat_entry() and get rid of PgStat_BackendFunctionEntry  (Michael Paquier <michael@paquier.xyz>)
Ответы Re: Reconcile stats in find_tabstat_entry() and get rid of PgStat_BackendFunctionEntry  (Michael Paquier <michael@paquier.xyz>)
Список 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 по дате отправления:

Предыдущее
От: Dmitry Koval
Дата:
Сообщение: Re: Add SPLIT PARTITION/MERGE PARTITIONS commands
Следующее
От: Jelte Fennema
Дата:
Сообщение: Re: running logical replication as the subscription owner