On Thu, 2006-12-14 at 19:05 -0500, Tom Lane wrote: > "Kelly Burkhart" <kelly.burkhart@xxxxxxxxx> writes: > > I hope this isn't a "crummy mainboard" but I can't seem to affect > > things by changing clock source (kernel 2.6.16 SLES10). I tried > > kernel command option clock=XXX where XXX in > > (cyclone,hpet,pmtmr,tsc,pit), no option was significantly better than > > the default. > > I believe that on machines where gettimeofday is really nice and fast, > it doesn't require entry to the kernel at all; there's some hack that > makes the clock readable from userspace. (Obviously a switch to kernel > mode would set you back a lot of the cycles involved here.) So it's not > so much the kernel that you need to teach as glibc. How you do that is > beyond my expertise, but maybe that will help you google for the right > thing ... 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) 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. -- Simon Riggs EnterpriseDB http://www.enterprisedb.com
