Re: RFC: Timing Events - Mailing list pgsql-hackers

From Jeff Janes
Subject Re: RFC: Timing Events
Date
Msg-id CAMkU=1yqwVYrUov7wde1odMuAOmQAtH9MeUYUqCgB0yukxmKOw@mail.gmail.com
Whole thread Raw
In response to Re: RFC: Timing Events  (Pavel Stehule <pavel.stehule@gmail.com>)
List pgsql-hackers
On Sun, Nov 4, 2012 at 1:35 AM, Pavel Stehule <pavel.stehule@gmail.com> wrote:
> Hello
>
> 2012/11/4 Satoshi Nagayasu <snaga@uptime.jp>:
>>>
>>
>> Do we have something to add to auto_explain?
>
> Now I am working on expanding slow query record and auto_explain with
> some locking times (lock on objects, lock on enhancing pages, other
> locks).

But this would only work if you used 'auto_explain.log_analyze=1',
which is has nasty performance implications.  Or you planning on
changing the way log_analyze works to get around this?

>
> Just statement time produces too less information in our complex and
> "unpredictable" cloud environment with thousand databases and hundreds
> servers.

I think it would be easier to implement but still a big step forward
over what we currently have if "explain analyze" and "\timing" would
show the 'rusage' values in addition to the wall-clock time.



pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Pg_upgrade speed for many tables
Next
From: Magnus Hagander
Date:
Subject: Re: Pg_upgrade speed for many tables