From: | Bruce Momjian <bruce(at)momjian(dot)us> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Joel Jacobson <joel(at)trustly(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: pg_stat_activity.waiting_start |
Date: | 2017-01-06 02:59:27 |
Message-ID: | 20170106025927.GB3063@momjian.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Dec 26, 2016 at 03:36:39PM -0500, Tom Lane wrote:
> In practice, there should never be waits on LWLocks (much less spinlocks)
> that exceed order-of-milliseconds; if there are, either we chose the wrong
> lock type or the system is pretty broken in general. So maybe it's
> sufficient if we provide a wait start time for heavyweight locks ...
> though that still seems kind of ugly. (Also, I don't recall the existing
> code factorization there, but getting the start time into pg_stat_activity
> without an extra gettimeofday call might be hard. As I said, there is
> one being done, but I'm not sure how accessible its result is.)
Agreed. No need in adding overhead for short-lived locks because the
milli-second values are going to be meaningless to users. I would be
happy if we could find some weasel value for non-heavyweight locks.
--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
From | Date | Subject | |
---|---|---|---|
Next Message | Tsunakawa, Takayuki | 2017-01-06 03:01:57 | Re: Supporting huge pages on Windows |
Previous Message | Vitaly Burovoy | 2017-01-06 02:39:09 | Re: Re: [BUGS][PATCH] BUG #14486: Inserting and selecting interval have different constraints |