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 1pjX6o-0001OF-Vz for pgsql-hackers@arkaria.postgresql.org; Tue, 04 Apr 2023 03:13:22 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1pjX6n-0004si-Fi for pgsql-hackers@arkaria.postgresql.org; Tue, 04 Apr 2023 03:13:21 +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 1pjX6n-0004sZ-6h for pgsql-hackers@lists.postgresql.org; Tue, 04 Apr 2023 03:13:21 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1pjX6k-000ka0-K3 for pgsql-hackers@postgresql.org; Tue, 04 Apr 2023 03:13:20 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 3343DCoM1311774; Mon, 3 Apr 2023 23:13:13 -0400 From: Tom Lane To: "Imseih (AWS), Sami" cc: Michael Paquier , "Drouvot, Bertrand" , David Zhang , "pgsql-hackers@postgresql.org" Subject: Re: [BUG] pg_stat_statements and extended query protocol In-reply-to: <75DD3F32-EB01-4540-8A19-1D8CDE490344@amazon.com> References: <3227719C-F7A3-4A94-B0A5-D27673316560@amazon.com> <0d583e2a-8214-4975-a4b4-7e9e0b8f8e9c@gmail.com> <472cfda7-1e4f-ed47-0860-78cf685b53b0@gmail.com> <8FFCD4F0-8B04-4EA2-9190-FEC70C376523@amazon.com> <1238702.1680540221@sss.pgh.pa.us> <1308756.1680576431@sss.pgh.pa.us> <75DD3F32-EB01-4540-8A19-1D8CDE490344@amazon.com> Comments: In-reply-to "Imseih (AWS), Sami" message dated "Tue, 04 Apr 2023 03:01:05 -0000" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1311772.1680577992.1@sss.pgh.pa.us> Date: Mon, 03 Apr 2023 23:13:12 -0400 Message-ID: <1311773.1680577992@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk "Imseih (AWS), Sami" writes: > I wonder if the right answer here is to track fetches as > a separate counter in pg_stat_statements, in which fetch > refers to the number of times a portal is executed? Maybe, but is there any field demand for that? IMV, the existing behavior is that we count one "call" per overall query execution (that is, per ExecutorEnd invocation). The argument that that's a bug and we should change it seems unsupportable to me, and even the argument that we should also count ExecutorRun calls seems quite lacking in evidence. We clearly do need to fix the reported rowcount for cases where ExecutorRun is invoked more than once per ExecutorEnd call; but I think that's sufficient. regards, tom lane