Re: query_id, pg_stat_activity, extended query protocol
От | Imseih (AWS), Sami |
---|---|
Тема | Re: query_id, pg_stat_activity, extended query protocol |
Дата | |
Msg-id | 3D09D9FF-FF82-4F38-AB30-0D5553D85729@amazon.com обсуждение исходный текст |
Ответ на | Re: query_id, pg_stat_activity, extended query protocol (Andrei Lepikhov <lepihov@gmail.com>) |
Ответы |
Re: query_id, pg_stat_activity, extended query protocol
|
Список | 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
В списке pgsql-hackers по дате отправления: