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 [EMAIL PROTECTED] Pervasive Software http://pervasive.com work: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461 ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
