Horton

Re: Patch: plan invalidation vs stored procedures

Hannu Krosing <hannu@2ndquadrant.com>

View thread View on postgr.es
From: Hannu Krosing <hannu@2ndQuadrant.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Alvaro Herrera <alvherre@commandprompt.com>, Dimitri Fontaine <dfontaine@hi-media.com>, Bruce Momjian <bruce@momjian.us>, Joshua Drake <jd@commandprompt.com>, Gregory Stark <stark@enterprisedb.com>, Asko Oja <ascoja@gmail.com>, Pavel Stehule <pavel.stehule@gmail.com>, pgsql-hackers@postgresql.org, Andrew Dunstan <andrew@dunslane.net>, David Fetter <david@fetter.org>, Martin Pihlak <martin.pihlak@gmail.com>
Date: 2008-08-19T21:11:07Z
Lists: pgsql-hackers 
On Tue, 2008-08-19 at 16:56 -0400, Tom Lane wrote:
> Alvaro Herrera <alvherre@commandprompt.com> writes:
> > The actual criterion is not really "new user-visible feature" versus
> > "bug fix".  It's more an attempt at measuring how large a potential
> > impact the change has.  The patch I saw was introducing a whole new
> > message type to go through the shared invalidation queue, which is not
> > something to be taken lightly (consider that there are three message
> > types of messages currently.)
> 
> I hadn't read it yet, but that makes it wrong already.  There's no need
> for any new inval traffic --- the existing syscache inval messages on
> pg_proc entries should serve fine.
> 
> 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.

-------------
Hannu