Alvaro Herrera <alvherre@commandprompt.com> writes:
> Wow, that is slow. Maybe a problem in the kernel? Perhaps something
> similar to this:
> http://www.ussg.iu.edu/hypermail/linux/kernel/0603.2/index.html#1282
Yeah, that's a pretty interesting thread. I came across something
similar on a Red Hat internal list. It seems there are three or four
different popular standards for clock hardware in the Intel world,
and some good implementations and some pretty bad implementations
of each. So the answer may well boil down to "if you're using cheap
junk PC hardware then gettimeofday will be slow".
In fact, I just got around to trying this on my old x86 PC, and
behold:
regression=# select count(*) from tenk1;count
-------10000
(1 row)
Time: 9.670 ms
regression=# explain analyze select count(*) from tenk1; QUERY PLAN
----------------------------------------------------------------------------------------------------------------Aggregate
(cost=470.00..470.01 rows=1 width=0) (actual time=93.549..93.553 rows=1 loops=1) -> Seq Scan on tenk1
(cost=0.00..445.00rows=10000 width=0) (actual time=0.014..49.261 rows=10000 loops=1)Total runtime: 93.663 ms
(3 rows)
Time: 94.431 ms
regression=#
So that says that this machine takes about 4 usec to do gettimeofday(),
as compared to 3 usec on my nominally 4x slower HPPA machine.
The new dual Xeon sitting next to it probably has a much less junky
motherboard, with a better clock ... and I find it unsurprising that
the HP and Apple machines I was trying aren't subject to such problems.
I didn't get the impression from that linux-kernel thread that the
proposed patch had actually gone in yet anyplace; anyone know how to
track that?
regards, tom lane