From: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com> |
---|---|
To: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
Cc: | Satoshi Nagayasu <snaga(at)uptime(dot)jp>, Josh Berkus <josh(at)agliodbs(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: RFC: Timing Events |
Date: | 2012-11-05 20:57:27 |
Message-ID: | CAMkU=1yqwVYrUov7wde1odMuAOmQAtH9MeUYUqCgB0yukxmKOw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sun, Nov 4, 2012 at 1:35 AM, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> wrote:
> Hello
>
> 2012/11/4 Satoshi Nagayasu <snaga(at)uptime(dot)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.
From | Date | Subject | |
---|---|---|---|
Next Message | Magnus Hagander | 2012-11-05 21:01:22 | Re: Pg_upgrade speed for many tables |
Previous Message | Bruce Momjian | 2012-11-05 20:49:08 | Re: Pg_upgrade speed for many tables |