Re: That EXPLAIN ANALYZE patch still needs work - Mailing list pgsql-hackers

From Mark Kirkwood
Subject Re: That EXPLAIN ANALYZE patch still needs work
Date
Msg-id 4488B995.1000302@paradise.net.nz
Whole thread Raw
In response to Re: That EXPLAIN ANALYZE patch still needs work  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: That EXPLAIN ANALYZE patch still needs work  (Agent M <agentm@themactionfaction.com>)
List pgsql-hackers
Tom Lane wrote:
> 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".
> 

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



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: self-deadlock at FATAL exit of boostrap process on read error
Next
From: Tom Lane
Date:
Subject: Re: TODO: Determine optimal fdatasync/fsync, O_SYNC/O_DSYNC options