Chris Browne wrote:
> Lukas Smith <mls@pooteeweet.org> writes:
> > Bruce Momjian wrote:
> >
> >> * Flush cached query plans when the dependent objects change,
> >> when the cardinality of parameters changes dramatically, or
> >> when new ANALYZE statistics are available
> >
> > Wouldn't it also make sense to flush a cached query plan when after
> > execution it is determined that one or more assumptions that the
> > cached query plan was based on was found to be off? Like the query
> > plan was based on the assumption that a particular table would only
> > return a hand full of rows, but in reality it returned a few
> > thousand.
>
> There is some merit to that.
>
> I could also see it being sensible to flush a cached plan any time the
> query took more than some [arbitrary/GUC-chosen] interval.
>
> Supposing it took 20s to execute the query, it would surely seem
> surprising for re-evaluating the plan to be expected to make up a
> material proportion of the cost of the *next* invocation.
>
> If we flush every plan that took >10s to evaluate, that offers the
> possibility for it to be done better next time...
Ah, but how do you pass that information back to the optimizer so you
don't end up getting the same plan again?
-- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610)
359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square,
Pennsylvania19073