Re: [HACKERS] pg_stat_activity.waiting_start

Поиск
Список
Период
Сортировка
От Joel Jacobson
Тема Re: [HACKERS] pg_stat_activity.waiting_start
Дата
Msg-id CAASwCXfeUCtH=v0y--P8hXGscuDTD7CGfAOgHhAB0xu68gArrg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] pg_stat_activity.waiting_start  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: [HACKERS] pg_stat_activity.waiting_start  (Joel Jacobson <joel@trustly.com>)
Re: [HACKERS] pg_stat_activity.waiting_start  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Sat, Dec 24, 2016 at 9:00 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> I would like to propose adding a fourth such column, "waiting_start",
>> which would tell how long time a backend has been waiting.
>
> The difficulty with that is it'd require a gettimeofday() call for
> every wait start.  Even on platforms where those are relatively cheap,
> the overhead would be nasty --- and on some platforms, it'd be
> astonishingly bad.  We sweated quite a lot to get the overhead of
> pg_stat_activity wait monitoring down to the point where it would be
> tolerable for non-heavyweight locks, but I'm afraid this would push
> it back into the not-tolerable range.

I don't think we need the microsecond resolution provided by
gettimeofday() via GetCurrentTimestamp()
It would be enough to know which second the waiting started, so we
could use time().

gettimeofday() takes 42 cycles.
time() only takes 3 cycles. [1]

[1] http://stackoverflow.com/questions/6498972/faster-equivalent-of-gettimeofday



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

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: Re: [HACKERS] Indirect indexes
Следующее
От: Joel Jacobson
Дата:
Сообщение: Re: [HACKERS] pg_stat_activity.waiting_start