Re: RFC: Logging plan of the running query
От | Fujii Masao |
---|---|
Тема | Re: RFC: Logging plan of the running query |
Дата | |
Msg-id | 5ab22d89-a9b9-bcc0-7e91-d4ce7935d050@oss.nttdata.com обсуждение исходный текст |
Ответ на | Re: RFC: Logging plan of the running query (torikoshia <torikoshia@oss.nttdata.com>) |
Ответы |
Re: RFC: Logging plan of the running query
|
Список | pgsql-hackers |
On 2021/06/09 16:44, torikoshia wrote: > Updated the patch. Thanks for updating the patch! auto_explain can log the plan of even nested statement if auto_explain.log_nested_statements is enabled. But ISTM that pg_log_current_plan() cannot log that plan. Is this intentional? I think that it's better to make pg_log_current_plan() log the plan of even nested statement. + es->format = EXPLAIN_FORMAT_TEXT; + es->settings = true; Since pg_log_current_plan() is usually used to investigate and trouble-shoot the long running queries, IMO it's better to enable es->verbose by default and get additional information about the queries. Thought? + * pg_log_current_plan + * Signal a backend process to log plan the of running query. "plan the of" is typo? + * Only superusers are allowed to signal to log plan because any users to + * issue this request at an unbounded rate would cause lots of log messages + * and which can lead to denial of service. "because any users" should be "because allowing any users" like the comment for pg_log_backend_memory_contexts()? + * All the actual work is deferred to ProcessLogExplainInterrupt(), "ProcessLogExplainInterrupt()" should be "ProcessLogCurrentPlanInterrupt()"? Regards, -- Fujii Masao Advanced Computing Technology Center Research and Development Headquarters NTT DATA CORPORATION
В списке pgsql-hackers по дате отправления: