Re: proposal 9.4. Explain on signal - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: proposal 9.4. Explain on signal
Date
Msg-id CAFj8pRB7MbTDx1CXNgUZ-LtnjOjRLGo=EB4ef3GE1RfPJehRCA@mail.gmail.com
Whole thread Raw
In response to Re: proposal 9.4. Explain on signal  (Thom Brown <thom@linux.com>)
Responses Re: proposal 9.4. Explain on signal  ("Dickson S. Guedes" <listas@guedesoft.net>)
List pgsql-hackers
2013/5/16 Thom Brown <thom@linux.com>:
> 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?
>

I would to get EXPLAIN of long queries without waiting on end.

So it is possible for manual cancelation (not for timeout)

SELECT pg_explain_backend(xx);
SELECT pg_cancel_backend(xx);

Regards

Pavel

> --
> Thom



pgsql-hackers by date:

Previous
From: Thom Brown
Date:
Subject: Re: proposal 9.4. Explain on signal
Next
From: Andres Freund
Date:
Subject: Re: Logging of PAM Authentication Failure