Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
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

pgsql-hackers by date

Next:From: Magnus HaganderDate: 2012-11-05 21:01:22
Subject: Re: Pg_upgrade speed for many tables
Previous:From: Bruce MomjianDate: 2012-11-05 20:49:08
Subject: Re: Pg_upgrade speed for many tables

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group