Re: [BUG] pg_stat_statements and extended query protocol

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

In response to

Responses

Browse pgsql-hackers by date

  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