From: | "Imseih (AWS), Sami" <simseih(at)amazon(dot)com> |
---|---|
To: | "Drouvot, Bertrand" <bertranddrouvot(dot)pg(at)gmail(dot)com>, Michael Paquier <michael(at)paquier(dot)xyz> |
Cc: | 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-22 21:35:23 |
Message-ID: | DF311964-77CB-4027-B00A-0AD7A3DB61D5@amazon.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> 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.
Regards,
--
Sami Imseih
Amazon Web Services (AWS)
Attachment | Content-Type | Size |
---|---|---|
v3-0001-Correct-accumulation-of-counters-for-extended-query-.patch | application/octet-stream | 4.2 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Geoghegan | 2023-03-22 21:41:50 | Re: HOT chain validation in verify_heapam() |
Previous Message | Euler Taveira | 2023-03-22 21:17:49 | Re: Initial Schema Sync for Logical Replication |