Re: [BUG] pg_stat_statements and extended query protocol - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: [BUG] pg_stat_statements and extended query protocol
Date
Msg-id ZABP6zdfymC0QKDX@paquier.xyz
Whole thread Raw
In response to [BUG] pg_stat_statements and extended query protocol  ("Imseih (AWS), Sami" <simseih@amazon.com>)
Responses Re: [BUG] pg_stat_statements and extended query protocol  ("Imseih (AWS), Sami" <simseih@amazon.com>)
Re: [BUG] pg_stat_statements and extended query protocol  ("Drouvot, Bertrand" <bertranddrouvot.pg@gmail.com>)
List pgsql-hackers
On Wed, Jan 25, 2023 at 11:22:04PM +0000, Imseih (AWS), Sami wrote:
> Doing some work with extended query protocol, I encountered the same
> issue that was discussed in [1]. It appears when a client is using
> extended query protocol and sends an Execute message to a portal with
> max_rows, and a portal is executed multiple times,
> pg_stat_statements does not correctly track rows and calls.

Well, it is one of these areas where it seems to me we have never been
able to put a definition on what should be the correct behavior when
it comes to pg_stat_statements.  Could it be possible to add some
regression tests using the recently-added \bind command and see how
this affects things?  I would suggest splitting these into their own
SQL file, following an effort I have been doing recently for the
regression tests of pg_stat_statements.  It would be good to know the
effects of this change for pg_stat_statements.track = (top|all), as
well.

@@ -657,7 +657,9 @@ typedef struct EState

        List       *es_tupleTable;      /* List of TupleTableSlots */

-       uint64          es_processed;   /* # of tuples processed */
+       uint64          es_processed;   /* # of tuples processed at the top level only */
+       uint64          es_calls;       /* # of calls */
+       uint64          es_total_processed; /* total # of tuples processed */

So the root of the logic is here.  Anything that makes the executor
structures larger freaks me out, FWIW, and that's quite an addition.
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: "Drouvot, Bertrand"
Date:
Subject: Re: Normalization of utility queries in pg_stat_statements
Next
From: Masahiko Sawada
Date:
Subject: Re: Should vacuum process config file reload more often