From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Larry Rosenman" <ler(at)lerctr(dot)org> |
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-09 14:00:20 |
Message-ID: | 9525.1149861620@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"Larry Rosenman" <ler(at)lerctr(dot)org> writes:
> Does my post from yesterday (39ms without explain analyze, 280+ with explain
> analyze) on FreeBSD/amd64, Dual Xeon's in HTT mode help?
Well, it confirms that FreeBSD is subject to the same problem ;-).
I think the bottom line here is that there are some machines out there
where gettimeofday() is fast enough for our purposes, and some where
it is nowhere near fast enough. And that kernel-level fixes may be
possible for some of the latter, but not all, and we shouldn't hold our
breath waiting for that to happen anyway.
To tell you the truth, this information makes me even less pleased with
the sampling-gettimeofday patch than I was before. If gettimeofday() in
itself increases the runtime of a node by a factor of 10, then just
trying to subtract off that time is no solution. There's too much
impact on surrounding nodes, and too much roundoff error anyhow.
I had thought we were applying an order-of-ten-percent correction by
subtracting SampleOverhead, not an order-of-10x correction :-(
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Nis Jorgensen | 2006-06-09 14:07:17 | Re: Fabian Pascal and RDBMS deficiencies in fully implementing |
Previous Message | Alvaro Herrera | 2006-06-09 13:58:02 | Re: That EXPLAIN ANALYZE patch still needs work |