Re: RFC: replace pg_stat_activity.waiting with something more descriptive - Mailing list pgsql-hackers

From Tom Lane
Subject Re: RFC: replace pg_stat_activity.waiting with something more descriptive
Date
Msg-id 3782.1437058499@sss.pgh.pa.us
Whole thread Raw
In response to Re: RFC: replace pg_stat_activity.waiting with something more descriptive  (Ildus Kurbangaliev <i.kurbangaliev@postgrespro.ru>)
Responses Re: RFC: replace pg_stat_activity.waiting with something more descriptive  (Robert Haas <robertmhaas@gmail.com>)
List 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 by date:

Previous
From: Petr Jelinek
Date:
Subject: Re: TABLESAMPLE patch is really in pretty sad shape
Next
From: Petr Jelinek
Date:
Subject: Re: TABLESAMPLE doesn't actually satisfy the SQL spec, does it?