| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Ildus Kurbangaliev <i(dot)kurbangaliev(at)postgrespro(dot)ru> |
| Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru>, Peter Eisentraut <peter_e(at)gmx(dot)net>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, Bruce Momjian <bruce(at)momjian(dot)us> |
| Subject: | Re: RFC: replace pg_stat_activity.waiting with something more descriptive |
| Date: | 2015-07-16 14:54:59 |
| Message-ID: | 3782.1437058499@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Ildus Kurbangaliev <i(dot)kurbangaliev(at)postgrespro(dot)ru> writes:
> I made benchmark of gettimeofday(). I believe it is certainly usable for monitoring.
> Testing configuration:
> 24 cores, Intel Xeon CPU X5675(at)3(dot)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(dot)1400021891(at)sss(dot)pgh(dot)pa(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Petr Jelinek | 2015-07-16 15:08:11 | Re: TABLESAMPLE doesn't actually satisfy the SQL spec, does it? |
| Previous Message | Petr Jelinek | 2015-07-16 14:45:58 | Re: TABLESAMPLE patch is really in pretty sad shape |