Alvaro Herrera <[EMAIL PROTECTED]> 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.00 rows=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 ---------------------------(end of broadcast)--------------------------- TIP 6: explain analyze is your friend