From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com> |
Cc: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Stephen Frost <sfrost(at)snowman(dot)net>, Joel Jacobson <joel(at)trustly(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: pg_stat_activity.waiting_start |
Date: | 2016-12-28 17:25:14 |
Message-ID: | 9663.1482945914@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Fabien COELHO | 2016-12-28 17:29:42 | Re: proposal: session server side variables |
Previous Message | Stephen Frost | 2016-12-28 17:25:06 | Re: Reporting planning time with EXPLAIN |