On Wed, 2003-10-01 at 22:43, Tom Lane wrote:
> Another issue is that we currently don't have a mechanism for flushing
> query plans when they become obsolete (eg, an index is added or
> removed). Locally-cached plans are relatively easy to refresh: just
> start a fresh session. A shared plan cache would retain bogus plans
> forever, short of a postmaster restart.
Well, keep in mind we already have DEALLOCATE for removing prepared
statements, which would continue to be available if we switched to
storing prepared statements in shared memory. However, using DEALLOCATE
to get around invalid cached plans is obviously not a good solution.
> Obviously we need a mechanism for detecting and handling cached-plan
> invalidations, and I hope someone will get around to that soon.
Agreed.
> But we *cannot* consider a shared plan cache until that mechanism
> exists.
Given the presence of DEALLOCATE, I think this overstates the case
somewhat: longer-lived prepared statements that are stored in shared
memory makes handling invalidated plans more of an issue, of course.
-Neil
