Re: Extremely irregular query performance

From: Kenneth Marshall
Subject: Re: Extremely irregular query performance
Date: ,
Msg-id: 20060112191618.GB81@it.is.rice.edu
(view: Whole thread, Raw)
In response to: Re: Extremely irregular query performance  (Simon Riggs)
List: pgsql-performance

Tree view

Extremely irregular query performance  (Jean-Philippe Côté<>, )
 Re: Extremely irregular query performance  (Tom Lane, )
  Re: Extremely irregular query performance  (Jean-Philippe Côté<>, )
   Re: Extremely irregular query performance  (Mark Lewis, )
   Re: Extremely irregular query performance  (Tom Lane, )
    Re: Extremely irregular query performance  (Simon Riggs, )
     Re: Extremely irregular query performance  (Kenneth Marshall, )
     Re: Extremely irregular query performance  (Bruce Momjian, )
      Re: Extremely irregular query performance  (Tom Lane, )
       Re: Extremely irregular query performance  (Bruce Momjian, )
 Re: Extremely irregular query performance  (Scott Marlowe, )
 Re: Extremely irregular query performance  (Jean-Philippe Cote, )
  Re: Extremely irregular query performance  (Bruce Momjian, )
  Re: Extremely irregular query performance  (Kenneth Marshall, )

On Thu, Jan 12, 2006 at 09:48:41AM +0000, Simon Riggs wrote:
> On Wed, 2006-01-11 at 22:23 -0500, Tom Lane wrote:
> > =?iso-8859-1?Q?Jean-Philippe_C=F4t=E9?= <> writes:
> > > Thanks a lot for this info, I was indeed exceeding the genetic
> > > optimizer's threshold.  Now that it is turned off, I get
> > > a very stable response time of 435ms (more or less 5ms) for
> > > the same query. It is about three times slower than the best
> > > I got with the genetic optimizer on, but the overall average
> > > is much lower.
> >
> > Hmm.  It would be interesting to use EXPLAIN ANALYZE to confirm that the
> > plan found this way is the same as the best plan found by GEQO, and
> > the extra couple hundred msec is the price you pay for the exhaustive
> > plan search.  If GEQO is managing to find a plan better than the regular
> > planner then we need to look into why ...
>
> It seems worth noting in the EXPLAIN whether GEQO has been used to find
> the plan, possibly along with other factors influencing the plan such as
> enable_* settings.
>

Is it the plan that is different in the fastest case with GEQO or is it
the time needed to plan that is causing the GEQO to beat the exhaustive
search?

Ken



pgsql-performance by date:

From: Kenneth Marshall
Date:
Subject: Re: Extremely irregular query performance
From: Tomka Gergely
Date:
Subject: big databases & hospitals