Skip site navigation (1) Skip section navigation (2)


From: "Simon Riggs" <simon(at)2ndquadrant(dot)com>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Kelly Burkhart" <kelly(dot)burkhart(at)gmail(dot)com>,"Evgeny Gridasov" <eugrid(at)fpm(dot)kubsu(dot)ru>,<pgsql-performance(at)postgresql(dot)org>,<pgsql-hackers(at)postgresql(dot)org>
Subject: Re: EXPLAIN ANALYZE on 8.2
Date: 2006-12-15 10:28:08
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackerspgsql-performance
On Thu, 2006-12-14 at 19:05 -0500, Tom Lane wrote:
> "Kelly Burkhart" <kelly(dot)burkhart(at)gmail(dot)com> 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:


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             

In response to


pgsql-performance by date

Next:From: Steinar H. GundersonDate: 2006-12-15 10:28:23
Subject: Re: New to PostgreSQL, performance considerations
Previous:From: Alexander StauboDate: 2006-12-15 09:53:25
Subject: Re: New to PostgreSQL, performance considerations

pgsql-hackers by date

Next:From: Martijn van OosterhoutDate: 2006-12-15 10:40:20
Subject: Re: invalid input syntax for type timestamp.
Previous:From: Martijn van OosterhoutDate: 2006-12-15 10:13:45
Subject: Re: Operator class group proposal

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group