It's worth noting that on Darwin (on Apple hardware) gettimeofday is
never a syscall whereas on Linux (AFAIK), it always is.
On Jun 8, 2006, at 7:58 PM, Mark Kirkwood wrote:
Tom Lane wrote:
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".
OS seems to matter as well - I've got two identical Supermicro P3TDER
dual intel boxes. 1 running FreeBSD 6.1, one running Gentoo Linux
2.6.16.
Doing the 'select count(*) vs explain analyze select count(*) on
100000 row table gives:
Freebsd : select 108 ms explain analyze 688 ms
Linux : select 100 ms explain analyze 196 ms
Both systems have ACPI enabled in BIOS (which means there is a better
timecounter than 'i8254' available (FreeBSD says its using 'ACPI-safe'
- not sure how to check on Linux).
¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬
AgentM
[EMAIL PROTECTED]
¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬
---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
