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

From Tom Lane
Subject Re: [HACKERS] pg_stat_activity.waiting_start
Date
Msg-id 9663.1482945914@sss.pgh.pa.us
Whole thread Raw
In response to Re: [HACKERS] pg_stat_activity.waiting_start  (Jim Nasby <Jim.Nasby@BlueTreble.com>)
Responses Re: [HACKERS] pg_stat_activity.waiting_start  (Jim Nasby <Jim.Nasby@BlueTreble.com>)
Re: [HACKERS] pg_stat_activity.waiting_start  (Amit Kapila <amit.kapila16@gmail.com>)
List pgsql-hackers
Jim Nasby <Jim.Nasby@BlueTreble.com> writes:
> On 12/28/16 7:10 AM, Amit Kapila wrote:
>> Can we think of introducing new guc trace_system_waits or something
>> like that which will indicate that the sessions will report the value
>> of wait_start in pg_stat_activity?

> In my experience the problem with those kind of settings is that they're 
> never enabled when you actually need them.

Yeah.  And they especially won't be enabled in production situations,
if people find out that they cause lots of overhead.

> I think it'd be much better 
> to find a way to always capture wait_starts that are over some minimum 
> duration, where collection overhead won't matter but you still have some 
> good info about what's going on. For pg_stat_activity I'd think that 
> threshold would be on the order of 50-100ms, though maybe there's other 
> places where a tighter tolerance would help.

The idea of just capturing the wait start for heavyweight locks, and
not other lock types, still seems superior to any of the alternatives
that have been suggested ...
        regards, tom lane



pgsql-hackers by date:

Previous
From: Stephen Frost
Date:
Subject: Re: [HACKERS] Reporting planning time with EXPLAIN
Next
From: Fabien COELHO
Date:
Subject: Re: [HACKERS] proposal: session server side variables