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.
--
Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461