On Wed, Dec 28, 2016 at 10:55 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Jim Nasby <jim.na...@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. >
I agree with that, but I think it might be better than nothing especially for LWLock waits. > Yeah. And they especially won't be enabled in production situations, > if people find out that they cause lots of overhead. > What kind of overhead are we expecting here? I think it probably depends on workload, but it is quite possible that in most workloads it is in single digit. I agree that in an ideal situation we should not allow even 1% overhead, however, if people are interested in doing the detail level of monitoring at the expense of some performance hit, then why not give them the option to do so. >> 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 ... > If we want to capture waits without any system level parameter, then that seems better option and maybe, later on, we can capture I/O waits as well. However, I feel as proposed the name of parameter wait_start can confuse users considering we have wait_event and wait_event_type for generic waits. -- With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
