Skip site navigation (1) Skip section navigation (2)

Re: PREPARE/EXECUTE across backends?

From: Neil Conway <neilc(at)samurai(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Jingren Zhou <jrzhoupro(at)hotmail(dot)com>,PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: PREPARE/EXECUTE across backends?
Date: 2003-10-02 02:53:23
Message-ID: 1065063202.3835.14.camel@tokyo (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
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.


> 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.


In response to

pgsql-hackers by date

Next:From: Peter EisentrautDate: 2003-10-02 06:37:08
Subject: Re: 7.4 status
Previous:From: Tom LaneDate: 2003-10-02 02:43:46
Subject: Re: PREPARE/EXECUTE across backends?

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group