Re: [HACKERS] pg_stat_activity.waiting_start
От | Tom Lane |
---|---|
Тема | Re: [HACKERS] pg_stat_activity.waiting_start |
Дата | |
Msg-id | 9647.1482545773@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | [HACKERS] pg_stat_activity.waiting_start (Joel Jacobson <joel@trustly.com>) |
Ответы |
Re: [HACKERS] pg_stat_activity.waiting_start
|
Список | pgsql-hackers |
Stephen Frost <sfrost@snowman.net> writes: > * Tom Lane (tgl@sss.pgh.pa.us) wrote: >> 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. > Could we handle this like log_lock_waits..? Well, that only applies to heavyweight locks, which do a gettimeofday anyway in order to schedule the deadlock-check timeout. If you were willing to populate this new column only for heavyweight locks, maybe it could be done for minimal overhead. But that would be backsliding quite a lot compared to what we just did to extend pg_stat_activity's coverage of lock types. regards, tom lane
В списке pgsql-hackers по дате отправления: