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

From Imseih (AWS), Sami
Subject Re: [BUG] pg_stat_statements and extended query protocol
Date
Msg-id 75DD3F32-EB01-4540-8A19-1D8CDE490344@amazon.com
Whole thread Raw
In response to Re: [BUG] pg_stat_statements and extended query protocol  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [BUG] pg_stat_statements and extended query protocol
List pgsql-hackers
> 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.

Correct, and there are also drivers that implement fetch size using
cursor statements, i.e. DECLARE CURSOR, FETCH CURSOR,
and each FETCH gets counted as 1 call.

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?

Regards,

Sami Imseih
Amazon Web Services (AWS)







pgsql-hackers by date:

Previous
From: tender wang
Date:
Subject: same query but different result on pg16devel and pg15.2
Next
From: Justin Pryzby
Date:
Subject: Re: zstd compression for pg_dump