From: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
---|---|
To: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: proposal for 9.5: monitoring lock time for slow queries |
Date: | 2014-08-13 05:21:31 |
Message-ID: | CAFj8pRAhQ-GZMABGOqU5VtxMcrVR8EEJojEMD_fhTSg3uciK7g@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi
2014-08-13 6:18 GMT+02:00 Michael Paquier <michael(dot)paquier(at)gmail(dot)com>:
> On Wed, Aug 13, 2014 at 4:59 AM, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
> wrote:
> > Any idea how to show a lock time in some practical form together with
> logged
> > slow query?
>
> Doing a join on pg_stat_activity and pg_locks is not going to help
> much as you could only get the moment when query has started or its
> state has changed. Have you thought about the addition of a new column
> in pg_locks containing the timestamp of the moment a lock has been
> taken? I am sure that we are concerned about the performance impact
> that extra calls to gettimeofday could have though...
> Regards,
>
There are two relative independent tasks
a) monitor and show total lock time of living queries
b) monitor and log total lock time of executed queries.
I am interested by @b now. When we work with slow query log, then we would
to identify reason for long duration. Locks are important source of these
queries on some systems.
What I know, we do monitoring these times for deadlock identification
trigger and for log_lock_waits - so there should not be any new pressure to
performance.
Regards
Pavel
> --
> Michael
>
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Stehule | 2014-08-13 05:22:24 | Re: proposal for 9.5: monitoring lock time for slow queries |
Previous Message | Tom Lane | 2014-08-13 05:19:44 | Re: proposal for 9.5: monitoring lock time for slow queries |