I'm not sure ... I thought I ran it on my P4 here in the office and saw itI will try to check this on my system.
too, albeit not near as frequently ... but, in FreeBSD's case, it is a
"design issue" ... there are two different functions, once that is kinda
fuzzy (but fast), and the other that is designed to be exact, but at a
performance loss ... or was it the same function, but a 'sysctl' variable
that changes the state?
Can't remember which, but it is by design on FreeBSD ... and, if we're talking about Apple, the same most likely applies, as its based on the same kernel ...
Back of my mind, I *think* it was these sysctl variables:
kern.timecounter.method: 0 kern.timecounter.hardware: i8254
But here another hint, maybe more interesting for Apple though: The bug does -not- occur if another process uses a lot of CPU time. We encoded a quicktime movie into mpeg2 and while this was using about 90% and while encoding the vcd i wanted to show the bug to a friend and it did not work.
But besides this, is there any chance that we can optimize our initial performance problem ;-)
regards David
---------------------------(end of broadcast)--------------------------- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
