| From: | "Imseih (AWS), Sami" <simseih(at)amazon(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Michael Paquier <michael(at)paquier(dot)xyz>, "Drouvot, Bertrand" <bertranddrouvot(dot)pg(at)gmail(dot)com>, David Zhang <david(dot)zhang(at)highgo(dot)ca>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: [BUG] pg_stat_statements and extended query protocol |
| Date: | 2023-04-04 03:01:05 |
| Message-ID: | 75DD3F32-EB01-4540-8A19-1D8CDE490344@amazon.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | 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)
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Justin Pryzby | 2023-04-04 03:04:02 | Re: zstd compression for pg_dump |
| Previous Message | tender wang | 2023-04-04 02:53:32 | same query but different result on pg16devel and pg15.2 |