On Sat, Dec 17, 2005 at 01:07:10PM -0500, Bruce Momjian wrote:
> Jim C. Nasby wrote:
> > Is cardinality the only thing we'd need to worry about? My idea was
> > actually to track the amount of work normally required by a stored query
> > plan, and if a query uses that plan but requires a very different amount
> > of work it's a good indication that we either need to replan or store
> > multiple plans for that query. Though if we're certain that cardinality
> > is the only thing that could make a cached plan go bad it would
> > certainly simplify things greatly.
>
> This gets into another area of re-optimizing when the executor finds
> that the actual tables don't match the optimizer estimates. I think we
> decided that was too hard/risky, but invalidating the plan might help,
> though I am thinking re-planning might just generate the same plan as
> before. I think something would need to have happened since the last
> planning, like ANALYZE or something.
Well, in the stored plan case, presumably what's changed is one of the
bound parameters. And if we want to be sophisticated about it, we won't
just throw out the old plan; rather we'll try and figure out what
parameter it is that's wanting a different plan.
> Updated TODO:
>
> * Flush cached query plans when the dependent objects change,
> when the cardinality of parameters changes dramatically, or
> when new ANALYZE statistics are available
Probably worth pointing to this therad in the TODO...
--
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
