Re: ToDo: log plans of cancelled queries - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: ToDo: log plans of cancelled queries
Date
Msg-id CAFj8pRCvrWFkzBREOABmT59GV7YA__B0uz-xhcDLCJCaNUq0zw@mail.gmail.com
Whole thread Raw
In response to Re: ToDo: log plans of cancelled queries  (Pavel Stehule <pavel.stehule@gmail.com>)
List pgsql-hackers
2013/1/11 Pavel Stehule <pavel.stehule@gmail.com>:
> 2013/1/11 Stephen Frost <sfrost@snowman.net>:
>> * Tom Lane (tgl@sss.pgh.pa.us) wrote:
>>> Simon Riggs <simon@2ndQuadrant.com> writes:
>>> > An even better feature would be to be able to send a signal to a
>>> > running query to log its currently executing plan. That way you can
>>> > ask "Why so slow?" before deciding to kill it.
>>>
>>> That could conceivably work.  At least it wouldn't require running
>>> EXPLAIN in a failed transaction.
>>
>> I like this idea, in general, also.  Taking that to the next level would
>> be figuring out how you can do the same kind of thing through an
>> interactive psql session where the user running the query doesn't need
>> access to the database server or PG log files...
>>
>
> this is simple - it can be printed via elog(WARNING, ...) to original console

theoretically we can show current state via EXPLAIN ANALYSE result

>
>> We can send a 'cancel query', how about a 'report on query' which
>> returns the plan and perhaps whatever other stats are easily available?
>
> there is only one question - that POSIX signal we can use?
>
> Pavel
>
>>
>>         Thanks,
>>
>>                 Stephen



pgsql-hackers by date:

Previous
From: Boszormenyi Zoltan
Date:
Subject: Re: Proposal for Allow postgresql.conf values to be changed via SQL [review]
Next
From: Stephen Frost
Date:
Subject: Re: psql \l to accept patterns