Re: [HACKERS] pg_stat_activity.waiting_start

Поиск
Список
Период
Сортировка
От Bruce Momjian
Тема Re: [HACKERS] pg_stat_activity.waiting_start
Дата
Msg-id 20170106025927.GB3063@momjian.us
обсуждение исходный текст
Ответ на Re: [HACKERS] pg_stat_activity.waiting_start  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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@momjian.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 +



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Vitaly Burovoy
Дата:
Сообщение: Re: [HACKERS] Re: [BUGS][PATCH] BUG #14486: Inserting and selectinginterval have different constraints
Следующее
От: "Tsunakawa, Takayuki"
Дата:
Сообщение: Re: [HACKERS] Supporting huge pages on Windows