Re: [HACKERS] pg_stat_activity.waiting_start - Mailing list pgsql-hackers

From Joel Jacobson
Subject Re: [HACKERS] pg_stat_activity.waiting_start
Date
Msg-id CAASwCXfeUCtH=v0y--P8hXGscuDTD7CGfAOgHhAB0xu68gArrg@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] pg_stat_activity.waiting_start  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [HACKERS] pg_stat_activity.waiting_start
Re: [HACKERS] pg_stat_activity.waiting_start
List 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 by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: [HACKERS] Indirect indexes
Next
From: Joel Jacobson
Date:
Subject: Re: [HACKERS] pg_stat_activity.waiting_start