On Wed, 2008-08-20 at 00:11 +0300, Hannu Krosing wrote:
> On Tue, 2008-08-19 at 16:56 -0400, Tom Lane wrote:
> >
> > More generally, if we are to try to invalidate on the strength of
> > pg_proc changes, what of other DDL changes? Operators, operator
> > classes, maybe? How about renaming a schema? I would like to see a
> > line drawn between things we find worth trying to track and things we
> > don't. If there is no such line, we're going to need a patch a lot
> > larger than this one.
>
> Or maybe a simpler and smaller patch - just invalidate everything on
> every schema change :)
>
> It will have a momentary impact on performance at DDL time, but
> otherways might be more robust and easier to check for errors.
I think Tom's main question is the right one: how much to invalidate?
ISTM that there must be some user defined control over how this occurs.
We have cascade and restrict as options in other places.
Being able to force replanning of everything when you know its the right
thing to do sounds sensible and useful. Being able to avoid it when you
know it isn't needed also sounds sensible and useful.
It would be useful to have an impact assessment tool, so we could say
"if I made this change, how many plans would it effect?". We can't do
that because the plans aren't shared. Perhaps that is a good argument
for a shared plan cache, or at least some way of defining whether some
plans are shared, some not.
-- Simon Riggs www.2ndQuadrant.comPostgreSQL Training, Services and Support