Re: more detailed description of tup_returned and tup_fetched

On 2021/05/18 20:10, Fujii Masao wrote:
>
>
> On 2021/05/18 18:23, Masahiro Ikeda wrote:
>>
>>
>> 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"?
>
> Yes, LGTM.
>
>
>>> 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.
>
> I was thinking that pg_stat_database.tup_fetched is the same as
> the sum of pg_stat_all_tables.idx_tup_fetch. Because they both
> are incremented by bitmap index scans, but pg_stat_all_indexes.idx_tup_read
> is not.

Yes. So, "Number of index entries returned by scans on indexes in this
database" is incorrect, and "Number of live rows fetched by index scans in
this database" is correct?

Regards,

--
Masahiro Ikeda
NTT DATA CORPORATION