On Fri, Dec 15, 2006 at 10:28:08AM +0000, Simon Riggs wrote: > Until we work out a better solution we can fix this in two ways: > > 1. EXPLAIN ANALYZE [ [ WITH | WITHOUT ] TIME STATISTICS ] ... > > 2. enable_analyze_timer = off | on (default) (USERSET) What exactly would this do? Only count actual rows or something? I wrote a patch that tried statistical sampling, but the figures were too far off for people's liking. > A performance drop of 4x-10x is simply unacceptable when trying to tune > queries where the current untuned time is already too high. Tying down > production servers for hours on end when we know for certain all they > are doing is calling gettimeofday millions of times is not good. This > quickly leads to the view from objective people that PostgreSQL doesn't > have a great optimizer, whatever we say in its defence. I don't want to > leave this alone, but I don't want to spend a month fixing it either. I think the best option is setitimer(), but it's not POSIX so platform support is going to be patchy. BTW, doing gettimeofday() without kernel entry is not really possible. You could use the cycle counter but it has the problem that if you have multiple CPUs you need to calibrate the result. If the CPU goes to sleep, there's is no way for the userspace process to know. Only the kernel has all the relevent information about what "time" is to get a reasonable result. Have a nice day, -- Martijn van Oosterhout <kleptog@xxxxxxxxx> http://svana.org/kleptog/ > From each according to his ability. To each according to his ability to litigate.
Attachment:
signature.asc
Description: Digital signature
