Second (as Tom says), some changes can hardly be traced. For example, we only use function A. But function A cites function B, function B cites function C. when C changes, how do we know that we should worry about our plan?
I don't see that this is a major problem. If a plan A invokes a function B, then changes to B will need to invalidate A; that should be pretty easy to arrange. If B is a PL/PgSQL function that invokes a function C, it will probably cache a plan involving C. But when C changes, we need only flush B's cached plan, _not_ A -- as far as A is concerned, the operation of B is a blackbox. The only exception is when B is a SQL function that is inlined, but we can handle that separately.
Regarding performance, the important point is that a DDL command "pushes" changes out to backends to invalidate cached plans -- a plan doesn't need to poll to see if there have been any changes to objects it depends upon. And on a production system, DDL should usually be infrequent (the primary exception is temp table creation/destruction, but we can potentially optimize for that since it is backend-local).
Or am I missing your point?
-Neil
---------------------------(end of broadcast)--------------------------- TIP 8: explain analyze is your friend
