Re: That EXPLAIN ANALYZE patch still needs work

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

In response to

Responses

Browse pgsql-hackers by date

  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