From: | Mark Kirkwood <markir(at)paradise(dot)net(dot)nz> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Martijn van Oosterhout <kleptog(at)svana(dot)org>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: That EXPLAIN ANALYZE patch still needs work |
Date: | 2006-06-08 23:58:13 |
Message-ID: | 4488B995.1000302@paradise.net.nz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane wrote:
> Alvaro Herrera <alvherre(at)commandprompt(dot)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".
>
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).
Cheers
Mark
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2006-06-09 00:00:53 | Re: TODO: Determine optimal fdatasync/fsync, O_SYNC/O_DSYNC options |
Previous Message | Tom Lane | 2006-06-08 23:56:47 | Re: self-deadlock at FATAL exit of boostrap process on read error |