Re: RFC: Logging plan of the running query
От | Bharath Rupireddy |
---|---|
Тема | Re: RFC: Logging plan of the running query |
Дата | |
Msg-id | CALj2ACWG16wSdkkPR93koq9JS84gYh93MruQaij8CX+hwydHTg@mail.gmail.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 Mon, Nov 15, 2021 at 6:29 PM torikoshia <torikoshia@oss.nttdata.com> wrote: > > 3) I think SendProcSignalForLogInfo can be more generic, meaning, it > > can also send signal to auxiliary processes if asked to do this will > > simplify the things for pg_log_backend_memory_contexts and other > > patches like pg_print_backtrace. I would imagine it to be "bool > > SendProcSignalForLogInfo(pid_t pid, ProcSignalReason reason, bool > > signal_aux_proc);". > > I agree with your idea. > Since sending signals to auxiliary processes to dump memory contexts and > pg_print_backtrace is still under discussion, IMHO it would be better to > refactor SendProcSignalForLogInfo after these patches are commited. +1. I have another comment: isn't it a good idea that an overloaded version of the new function pg_log_query_plan can take the available explain command options as a text argument? I'm not sure if it is possible to get the stats like buffers, costs etc of a running query, if yes, something like pg_log_query_plan(pid, 'buffers', 'costs'....);? It looks to be an overkill at first sight, but these can be useful to know more detailed plan of the query. Thoughts? Regards, Bharath Rupireddy.
В списке pgsql-hackers по дате отправления: