Re: proposal 9.4. Explain on signal
От | Thom Brown |
---|---|
Тема | Re: proposal 9.4. Explain on signal |
Дата | |
Msg-id | CAA-aLv7qzFy6Gg1kqZ3+21n=4Ajmw=uAgBFqi89KpcFukpz6Ww@mail.gmail.com обсуждение исходный текст |
Ответ на | proposal 9.4. Explain on signal (Pavel Stehule <pavel.stehule@gmail.com>) |
Ответы |
Re: proposal 9.4. Explain on signal
|
Список | pgsql-hackers |
On 16 May 2013 11:09, Pavel Stehule <pavel.stehule@gmail.com> wrote: > Hello > > I proposed a some months log plans of cancelled queries > http://www.postgresql.org/message-id/CAFj8pRA-DuzkmDtu52CiUgb0P7TVri_B8LtjMJfWcnr1LPts6w@mail.gmail.com > . After discussion the proposal was changed to get plan of any running > query. > > I have a proof concept patch now and I am thinking so it can work well > > So I propose following concept: > > 1. function pg_explain_backend(PID int, loglevel int default 'log', > explain_top_level boolean default true); > > Execution of this function ensure sending sigusr1 signal to PID process. > > 2. Sigusr1 handler will be enhanced for PROCSIG_EXPLAIN_MESSAGES > message and it will write explain result to log. > > > It share lot of code with auto_explain module. So I am thinking so we > should move auto_explain functionality to core. Then EXPLAIN ON SIGNAL > can be used for monitoring of query evaluating. What a neat idea. So the original plan of EXPLAINing cancelled queries... does this cater for that? Can cancelled queries automatically invoke the EXPLAIN functionality as part of this feature? -- Thom
В списке pgsql-hackers по дате отправления: