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 1pjWhf-00085x-Qy for pgsql-hackers@arkaria.postgresql.org; Tue, 04 Apr 2023 02:47:23 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1pjWhd-0000QR-La for pgsql-hackers@arkaria.postgresql.org; Tue, 04 Apr 2023 02:47:21 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pjWhd-0000QI-CG for pgsql-hackers@lists.postgresql.org; Tue, 04 Apr 2023 02:47:21 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pjWhb-0002ac-5F for pgsql-hackers@postgresql.org; Tue, 04 Apr 2023 02:47: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 3342lB8a1308757; Mon, 3 Apr 2023 22:47:11 -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: 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> Comments: In-reply-to "Imseih (AWS), Sami" message dated "Tue, 04 Apr 2023 02:19:46 -0000" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1308755.1680576431.1@sss.pgh.pa.us> Content-Transfer-Encoding: quoted-printable Date: Mon, 03 Apr 2023 22:47:11 -0400 Message-ID: <1308756.1680576431@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk "Imseih (AWS), Sami" writes: >> Also, I'm doubtful that counting calls this way is a great idea, >> which would mean you only need one new counter field not two. The >> fact that you're having trouble defining what it means certainly >> suggests that the implementation is out front of the design. > ISTM you are not in agreement that a call count should be incremented = > after every executorRun, but should only be incremented after = > the portal is closed, at executorEnd. Is that correct? Right. That makes the "call count" equal to the number of times the query is invoked. > FWIW, The rationale for incrementing calls in executorRun is that calls = refers = > to the number of times a client executes a portal, whether partially or = to completion. Why should that be the definition? Partial execution of a portal might be something that is happening at the driver level, behind the user's back. You can't make rational calculations of, say, plan time versus execution time if that's how "calls" is measured. regards, tom lane