From: | Yugo NAGATA <nagata(at)sraoss(dot)co(dot)jp> |
---|---|
To: | "Drouvot, Bertrand" <bertranddrouvot(dot)pg(at)gmail(dot)com> |
Cc: | "Imseih (AWS), Sami" <simseih(at)amazon(dot)com>, Michael Paquier <michael(at)paquier(dot)xyz>, 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-03-24 03:21:44 |
Message-ID: | 20230324122144.f38a097c1dc206c1f8aab2a3@sraoss.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, 23 Mar 2023 09:33:16 +0100
"Drouvot, Bertrand" <bertranddrouvot(dot)pg(at)gmail(dot)com> wrote:
> Hi,
>
> On 3/22/23 10:35 PM, Imseih (AWS), Sami wrote:
> >> What about using an uint64 for calls? That seems more appropriate to me (even if
> >> queryDesc->totaltime->calls will be passed (which is int64), but that's already
> >> also the case for the "rows" argument and queryDesc->totaltime->rows_processed)
> >
> > That's fair
> >
> >
> >> I'm not sure it's worth mentioning that the new counters are "currently" used with the ExecutorRun.
> >
> > Sure, I suppose these fields could be used outside of ExecutorRun. Good point.
> >
> >
> >> Also, I wonder if "rows" (and not rows_processed) would not be a better naming.
> >
> > Agree.
> >
> > I went with rows_processed initially, since it was accumulating es_processed,
> > but as the previous point, this instrumentation could be used outside of
> > ExecutorRun.
> >
> > v3 addresses the comments.
I wonder that this patch changes the meaning of "calls" in the pg_stat_statement
view a bit; previously it was "Number of times the statement was executed" as
described in the documentation, but currently this means "Number of times the
portal was executed". I'm worried that this makes users confused. For example,
a user may think the average numbers of rows returned by a statement is given by
rows/calls, but it is not always correct because some statements could be executed
with multiple portal runs.
Although it might not big issue to users, I think it is better to add an explanation
to the doc for clarification.
Regards,
Yugo Nagata
> >
>
> Thanks! LGTM and also do confirm that, with the patch, the JDBC test does show the correct results.
>
> That said, not having a test (for the reasons you explained up-thread) associated with the patch worry me a bit.
>
> But, I'm tempted to say that adding new tests could be addressed separately though (as this patch looks pretty straightforward).
>
> Regards,
>
> --
> Bertrand Drouvot
> PostgreSQL Contributors Team
> RDS Open Source Databases
> Amazon Web Services: https://aws.amazon.com
>
>
--
Yugo NAGATA <nagata(at)sraoss(dot)co(dot)jp>
From | Date | Subject | |
---|---|---|---|
Next Message | Bharath Rupireddy | 2023-03-24 03:25:07 | Re: add log messages when replication slots become active and inactive (was Re: Is it worth adding ReplicationSlot active_pid to ReplicationSlotPersistentData?) |
Previous Message | Kyotaro Horiguchi | 2023-03-24 03:01:16 | Re: Error "initial slot snapshot too large" in create replication slot |