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
|
Список | 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 по дате отправления: