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