Re: invalidating cached plans

Qingqing Zhou wrote:
> 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