Re: RFC: Timing Events

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.

In response to

Browse pgsql-hackers by date

  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