Re: That EXPLAIN ANALYZE patch still needs work

>>>>> "MvO" == Martijn van Oosterhout <kleptog(at)svana(dot)org> writes:

MvO> What we want is just a monotonically increasing counter that can
MvO> be read quickly and consistantly, we're not majorly fussed if it
MvO> doesn't match real time. This puts us back to CPU cycle counters,
MvO> but they have drawbacks of their own.

It is amazing how this discussion is mirroring discussions on the
linux-kernel list.

Applications have been using CPU cycle counters on Linux to avoid the
gettimeofday() overhead. With reasonably recent kernels, the overhead
is very low when the CPU cycle counters are usable, because
gettimeofday() never actually enters kernel space.

Unfortunately fewer and fewer systems seem to have usable cycle
counters. As an example, dual core Athlon64/Opteron boots with the
cycle counters unsynced. The kernel can compensate for that. However
they also lose sync whenever clock frequency changes, and the kernel
has a really hard time compensating for it. On such systems the kernel
switches back to slower timers and gettimeofday() becomes a real
system call. Applications should not try to use cycle counters
directly on such systems. If the kernel developers manage a good
workaround, gettimeofday() becomes fast again, but applications which
use cycle counters most likely stay broken.

Basically either gettimeofday() is fast, or the cycle counters are
useless -- unless you really care about counting CPU cycles and not
real time. Some CPUs like Transmetas actually get the counter thing
right and count 2 every tick when running at half speed and so on.

/Benny