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
This would at least make it easy for admins to identify prepared queries
that have a highly variable execution cost.
Jim C. Nasby, Sr. Engineering Consultant jnasby(at)pervasive(dot)com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
In response to
pgsql-hackers by date
|Next:||From: Stephen Frost||Date: 2005-12-22 02:06:38|
|Subject: Re: horology regression test failure|
|Previous:||From: Manfred Koizar||Date: 2005-12-22 00:43:34|
|Subject: Re: Re: Which qsort is used |