Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lirEF-0000M9-12 for pgsql-docs@arkaria.postgresql.org; Tue, 18 May 2021 04:21:11 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1lirED-0001Kf-T3 for pgsql-docs@arkaria.postgresql.org; Tue, 18 May 2021 04:21:09 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lirED-0001KX-N9 for pgsql-docs@lists.postgresql.org; Tue, 18 May 2021 04:21:09 +0000 Received: from oss.nttdata.com ([49.212.34.109]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lirE8-0002ik-N3 for pgsql-docs@lists.postgresql.org; Tue, 18 May 2021 04:21:09 +0000 Received: from [192.168.0.6] (124-144-135-173.rev.home.ne.jp [124.144.135.173]) by oss.nttdata.com (Postfix) with ESMTPSA id 4CAB560256; Tue, 18 May 2021 13:21:00 +0900 (JST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.2 at oss.nttdata.com From: Masahiro Ikeda Subject: Re: more detailed description of tup_returned and tup_fetched To: Fujii Masao , pgsql-docs@lists.postgresql.org References: <9eeeccdb-5dd7-90f9-2807-a4b5d2b76ca3@oss.nttdata.com> <19f98fd2-c81b-f77f-d940-2816c565f850@oss.nttdata.com> <03d26cbe-cce3-5cdf-89e6-df3769ff7728@oss.nttdata.com> Message-ID: <14c6b74b-bb73-f8eb-3ce7-3e903e651bd3@oss.nttdata.com> Date: Tue, 18 May 2021 13:20:59 +0900 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 MIME-Version: 1.0 In-Reply-To: <03d26cbe-cce3-5cdf-89e6-df3769ff7728@oss.nttdata.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 2021/05/17 20:46, Fujii Masao wrote: > > > On 2021/05/17 18:58, Masahiro Ikeda wrote: >> >> >> On 2021/05/17 15:32, Fujii Masao wrote: >>> >>> >>> On 2021/05/14 17:00, Masahiro Ikeda wrote: >>>> Hi, >>>> >>>> I worried the difference between "tup_returned" and "tup_fetched" in >>>> pg_stat_database. I assumed that "tup_returned" means the number of tuples >>>> that returned to clients. Of course, this is wrong. >>> >>> -       Number of rows returned by queries in this database >>> +       Number of live rows returned by sequential scans of queries in this >>> database >>> >>> -       Number of rows fetched by queries in this database >>> +       Number of live rows fetched by index scan of queries in this database >>> >>> I found the following comments in pgstat.h. So maybe even these >>> new descriptions are incorrect? >>> >>>   * Note: for a table, tuples_returned is the number of tuples successfully >>>   * fetched by heap_getnext, while tuples_fetched is the number of tuples >>>   * successfully fetched by heap_fetch under the control of bitmap indexscans. >>>   * For an index, tuples_returned is the number of index entries returned by >>>   * the index AM, while tuples_fetched is the number of tuples successfully >>>   * fetched by heap_fetch under the control of simple indexscans for this >>> index. >> >> Oh, Thanks! >> >> I updated the sentences using the descriptions of >> "pg_stat_all_tables.seq_tup_read", "pg_stat_all_tables.idx_tup_fetch", and >> "pg_stat_all_index.idx_tup_read". >> >> -       Number of rows returned by queries in this database >> +       Number of rows returned by queries in this database. The rows >> correspond to the live rows fetched by sequential scans and index entries >> returned by scans on indexes > > This is still not correct because this counter is incremented even when > other scan like TidScan happens? Sorry, I couldn't find the way to increment tup_returned by TidScan. Do you mean that Tid Range Scan increments the counter? 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. That's the reason why the document of pg_stat_all_tables.seq_tup_read says "Number of live rows fetched by sequential scans" Regards, -- Masahiro Ikeda NTT DATA CORPORATION