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 DF311964-77CB-4027-B00A-0AD7A3DB61D5@amazon.com
Whole thread Raw
In response to Re: [BUG] pg_stat_statements and extended query protocol  ("Drouvot, Bertrand" <bertranddrouvot.pg@gmail.com>)
Responses Re: [BUG] pg_stat_statements and extended query protocol  ("Drouvot, Bertrand" <bertranddrouvot.pg@gmail.com>)
List 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

pgsql-hackers by date:

Previous
From: "Euler Taveira"
Date:
Subject: Re: Initial Schema Sync for Logical Replication
Next
From: Peter Geoghegan
Date:
Subject: Re: HOT chain validation in verify_heapam()