Re: more detailed description of tup_returned and tup_fetched

Поиск
Список
Период
Сортировка
От Masahiro Ikeda
Тема Re: more detailed description of tup_returned and tup_fetched
Дата
Msg-id ebef239a-b44f-1a5e-4548-dc055070a5dc@oss.nttdata.com
обсуждение исходный текст
Ответ на Re: more detailed description of tup_returned and tup_fetched  (Fujii Masao <masao.fujii@oss.nttdata.com>)
Ответы Re: more detailed description of tup_returned and tup_fetched  (Fujii Masao <masao.fujii@oss.nttdata.com>)
Список pgsql-docs

On 2021/05/18 16:01, Fujii Masao wrote:
> On 2021/05/18 13:20, Masahiro Ikeda wrote:
>> Tid Range Scan increments the tup_returned, and
>> pg_stat_all_tables.seq_tup_read is also incremented. I thought it's ok because
>> Tid Range Scan is like sequential scan.
> 
> Yes, you're right. One interesting thing I found is;
> when Tid Range Scan happens, seq_tup_read is incremented
> but seq_scan is not. I'm not sure if this is expected behavior or not.

The following comment says that this behavior is expected. But, I agree it's
odd and it's natural both seq_tup_read and seq_scan are incremented at the
same time or not...

/*
 * Currently, we only have a stats counter for sequential heap scans (but
 * e.g for bitmap scans the underlying bitmap index scans will be counted,
 * and for sample scans we update stats for tuple fetches).
 */
if (scan->rs_base.rs_flags & SO_TYPE_SEQSCAN)
    pgstat_count_heap_scan(scan->rs_base.rs_rd);


>> That's the reason why the document of
>> pg_stat_all_tables.seq_tup_read says "Number of live rows fetched by
>> sequential scans"
> 
> Regarding the original issue, as far as I understand correctly,
> 
> * pg_stat_database.tup_returned = sum(pg_stat_all_tables.seq_tup_read) +
> sum(pg_stat_all_indexes.idx_tup_read)
> * pg_stat_database.tup_fetched = sum(pg_stat_all_tables.idx_tup_fetch)
> 
> But the counters for some system catalogs like pg_database shared
> across all databases of a cluster are excluded from that calculation.
> Is this my understanding right? If right, probably we can reuse
> the existing descriptions for those counters to document
> pg_stat_database counters. For example,

Yes, my understanding is same now.


> pg_stat_database.tup_returned:> Number of live rows fetched by sequential and index scans in this database

I wonder "live rows fetched by index scans" may mislead. I think "live" means
it's not dead tuple and "rows" mean the tuple user want to get.

But, pg_stat_all_indexes.idx_tup_read says that "index entires returned by
scans on this index". There is no meaning of "live" and "rows", so I thought
it's better to distinguish them.

So, why don't you change to "Number of live rows fetched by sequential scans
and index entries returned by index scans in this database"?


> pg_stat_database.tup_fetched:
> Number of index entries returned by scans on indexes in this database
Is this the sum of pg_stat_all_indexes.idx_tup_read? This is accounted to
pg_stat_database.tup_returned.

"Number of live rows fetched by index scans in this database" seems to be correct.


Regards,
-- 
Masahiro Ikeda
NTT DATA CORPORATION



В списке pgsql-docs по дате отправления:

Предыдущее
От: Moin Akther
Дата:
Сообщение: pgpool: APPARENT DEADLOCK!!! Complete Status: Managed Threads: 3 Active Threads: 3
Следующее
От: Fujii Masao
Дата:
Сообщение: Re: more detailed description of tup_returned and tup_fetched