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

Re: Automatic function replanning

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com>
Cc: Rick Gigger <rick(at)alpinenetworking(dot)com>, Neil Conway <neilc(at)samurai(dot)com>, Joachim Wieland <joe(at)mcknight(dot)de>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Automatic function replanning
Date: 2005-12-22 04:00:31
Message-ID: 200512220400.jBM40Vl19276@candle.pha.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
Jim C. Nasby wrote:
> On Wed, Dec 21, 2005 at 05:43:38PM -0500, Bruce Momjian wrote:
> > Rick Gigger wrote:
> > > It seems to me like there are two classes of problems here:
> > > 
> > > 1) Simply invalidating plans made with out of date statistics.
> > > 2) Using run-time collected data to update the plan to something more  
> > > intelligent.
> > > 
> > > It also seems like #1 would be fairly straightforward and simple  
> > > whereas #2 would be much more complex.  #1 would do me a world of  
> > > good and probably other people as well.  Postgres's query planning  
> > > has always been fine for me, or at least I have always been able to  
> > > optimize my queries when I've got a representative data set to work  
> > > with.  Query plan caching only gets me when the query plan is created  
> > > before the statistics are present to create a good plan.
> > > 
> > > Just one users 2 cents.
> > 
> > Agreed.  I just can't add #2 unless we get more agreement from the
> > group, because it has been a disputed issue in the past.
> 
> Well, how about this, since it's a prerequisit for #2 and would be
> generally useful anyway:
> 
> Track normal resource consumption (ie: tuples read) for planned queries
> and record parameter values that result in drastically different
> resource consumption.
> 
> This would at least make it easy for admins to identify prepared queries
> that have a highly variable execution cost.

We have that TODO already:

	* Log statements where the optimizer row estimates were dramatically
	  different from the number of rows actually found?

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman(at)candle(dot)pha(dot)pa(dot)us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

In response to

Responses

pgsql-hackers by date

Next:From: Bruce MomjianDate: 2005-12-22 04:07:13
Subject: Re: Does VACUUM reorder tables on clustered indices
Previous:From: Qingqing ZhouDate: 2005-12-22 03:49:45
Subject: Re: to_char and i18n

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