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
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
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.

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

In response to

Browse pgsql-hackers by date

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