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

Re: EXPLAIN ANALYZE on 8.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: 1166178488.3882.56.camel@silverbirch.site (view raw or flat)
Thread:
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:

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



In response to

Responses

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-2014 The PostgreSQL Global Development Group