Re: [HACKERS] pg_stat_activity.waiting_start

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [HACKERS] pg_stat_activity.waiting_start
Дата
Msg-id 9663.1482945914@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: [HACKERS] pg_stat_activity.waiting_start  (Jim Nasby <Jim.Nasby@BlueTreble.com>)
Ответы 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>)
Список 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 по дате отправления:

Предыдущее
От: Stephen Frost
Дата:
Сообщение: Re: [HACKERS] Reporting planning time with EXPLAIN
Следующее
От: Fabien COELHO
Дата:
Сообщение: Re: [HACKERS] proposal: session server side variables