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

Re: PREPARE/EXECUTE across backends?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Neil Conway <neilc(at)samurai(dot)com>
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:43:46
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Neil Conway <neilc(at)samurai(dot)com> writes:
> The decision to store prepared statements per-backend, rather than in
> shared memory, was made deliberately. In fact, an early version of the
> PREPARE/EXECUTE patch (written by Karel Zak) stored prepared statements
> in shared memory. But I decided to remove this, because:
> [ several good reasons ]

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.

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

If I recall correctly, Karel's original shared plan cache also triggered
a lot of concern about contention for the shared data structure ...
I'm not convinced that it would be a big bottleneck, but there's
definitely an issue to think about there ...

			regards, tom lane

In response to


pgsql-hackers by date

Next:From: Neil ConwayDate: 2003-10-02 02:53:23
Subject: Re: PREPARE/EXECUTE across backends?
Previous:From: Kris JurkaDate: 2003-10-02 02:10:23
Subject: Re: PREPARE/EXECUTE across backends?

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