Re: Patch: plan invalidation vs stored procedures

From: Simon Riggs <simon(at)2ndQuadrant(dot)com>
To: Hannu Krosing <hannu(at)2ndQuadrant(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Dimitri Fontaine <dfontaine(at)hi-media(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, Joshua Drake <jd(at)commandprompt(dot)com>, Gregory Stark <stark(at)enterprisedb(dot)com>, Asko Oja <ascoja(at)gmail(dot)com>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org, Andrew Dunstan <andrew(at)dunslane(dot)net>, David Fetter <david(at)fetter(dot)org>, Martin Pihlak <martin(dot)pihlak(at)gmail(dot)com>
Subject: Re: Patch: plan invalidation vs stored procedures
Date: 2008-08-19 22:53:54
Message-ID: 1219186434.5343.1076.camel@ebony.2ndQuadrant
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


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.com
PostgreSQL Training, Services and Support

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message daveg 2008-08-19 22:59:42 Re: A smaller default postgresql.conf
Previous Message Hiroshi Saito 2008-08-19 22:37:14 Re: compilig libpq with borland 5.5