Re: RFC: replace pg_stat_activity.waiting with something more descriptive

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: RFC: replace pg_stat_activity.waiting with something more descriptive
Дата
Msg-id 3782.1437058499@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: RFC: replace pg_stat_activity.waiting with something more descriptive  (Ildus Kurbangaliev <i.kurbangaliev@postgrespro.ru>)
Ответы Re: RFC: replace pg_stat_activity.waiting with something more descriptive  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
Ildus Kurbangaliev <i.kurbangaliev@postgrespro.ru> writes:
> I made benchmark of gettimeofday(). I believe it is certainly usable for monitoring.
> Testing configuration:
> 24 cores,  Intel Xeon CPU X5675@3.07Ghz
> RAM 24 GB

> 54179703 - microseconds total
> 2147483647 - (INT_MAX), the number of gettimeofday() calls

>     >>> 54179703 / 2147483647.0
>     0.025229390256679331

> Here we have the average duration of one gettimeofday in microseconds.

25 nsec per gettimeofday() is in the same ballpark as what I measured
on a new-ish machine last year:
http://www.postgresql.org/message-id/flat/31856.1400021891@sss.pgh.pa.us

The problem is that (a) on modern hardware that is not a small number,
it's the equivalent of 100 or more instructions; and (b) the results
look very much worse on less-modern hardware, particularly machines
where gettimeofday requires a kernel call.
        regards, tom lane



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Petr Jelinek
Дата:
Сообщение: Re: TABLESAMPLE patch is really in pretty sad shape
Следующее
От: Petr Jelinek
Дата:
Сообщение: Re: TABLESAMPLE doesn't actually satisfy the SQL spec, does it?