From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | "Imseih (AWS), Sami" <simseih(at)amazon(dot)com> |
Cc: | "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [BUG] pg_stat_statements and extended query protocol |
Date: | 2023-03-02 07:27:39 |
Message-ID: | ZABP6zdfymC0QKDX@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Masahiko Sawada | 2023-03-02 07:36:09 | Re: Should vacuum process config file reload more often |
Previous Message | Drouvot, Bertrand | 2023-03-02 07:12:24 | Re: Normalization of utility queries in pg_stat_statements |