| From: | "Imseih (AWS), Sami" <simseih(at)amazon(dot)com> |
|---|---|
| To: | Andrei Lepikhov <lepihov(at)gmail(dot)com>, Michael Paquier <michael(at)paquier(dot)xyz> |
| Cc: | kaido vaikla <kaido(dot)vaikla(at)gmail(dot)com>, "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: query_id, pg_stat_activity, extended query protocol |
| Date: | 2024-05-16 20:34:54 |
| Message-ID: | 3D09D9FF-FF82-4F38-AB30-0D5553D85729@amazon.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> I'm unsure if it needs to call ExecutorStart in the bind code. But if we
> don't change the current logic, would it make more sense to move
> pgstat_report_query_id to the ExecutorRun routine?
I initially thought about that, but for utility statements (CTAS, etc.) being
executed with extended query protocol, we will still not advertise the queryId
as we should. This is why I chose to set the queryId in PortalRunSelect and
PortalRunMulti in v2 of the patch [1].
We can advertise the queryId inside ExecutorRun instead of
PortalRunSelect as the patch does, but we will still need to advertise
the queryId inside PortalRunMulti.
[1] https://www.postgresql.org/message-id/FAB6AEA1-AB5E-4DFF-9A2E-BB320E6C3DF1%40amazon.com
Regards,
Sami
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Melanie Plageman | 2024-05-16 20:46:16 | Re: commitfest.postgresql.org is no longer fit for purpose |
| Previous Message | Joe Conway | 2024-05-16 20:31:01 | Re: commitfest.postgresql.org is no longer fit for purpose |