"Larry Rosenman" <ler@lerctr.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 ---------------------------(end of broadcast)--------------------------- TIP 5: don't forget to increase your free space map settings