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 ---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster
