From: Simon Riggs <simon@2ndquadrant.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Kelly Burkhart <kelly.burkhart@gmail.com>
Cc: Evgeny Gridasov <eugrid@fpm.kubsu.ru>
Cc: pgsql-performance@postgresql.org
Cc: pgsql-hackers@postgresql.org
Subject: Re: EXPLAIN ANALYZE on 8.2
Date: Fri, 15 Dec 2006 10:28:08 +0000
Message-ID: <1166178488.3882.56.camel@silverbirch.site> (raw)
In-Reply-To: <29450.1166141131@sss.pgh.pa.us>
References: <20061214163230.d46f0138.eugrid@fpm.kubsu.ru>
<21146.1166112702@sss.pgh.pa.us>
<20061214192920.c75385d6.eugrid@fpm.kubsu.ru>
<21516.1166114475@sss.pgh.pa.us>
<fa1e4ce70612141543o8866d7fg417eca88ce9b1344@mail.gmail.com>
<29450.1166141131@sss.pgh.pa.us>
On Thu, 2006-12-14 at 19:05 -0500, Tom Lane wrote:
> "Kelly Burkhart" <kelly.burkhart@gmail.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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: simon@2ndquadrant.com, tgl@sss.pgh.pa.us, kelly.burkhart@gmail.com, eugrid@fpm.kubsu.ru, pgsql-hackers@postgresql.org
Subject: Re: EXPLAIN ANALYZE on 8.2
In-Reply-To: <1166178488.3882.56.camel@silverbirch.site>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox