Re: That EXPLAIN ANALYZE patch still needs work

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

In response to

Responses

Browse pgsql-hackers by date

  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