Re: 7.3 schedule

From: Neil Conway <nconway(at)klamath(dot)dyndns(dot)org>
To: "Bruce Momjian" <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: tgl(at)sss(dot)pgh(dot)pa(dot)us, zakkr(at)zf(dot)jcu(dot)cz, pgsql-hackers(at)postgresql(dot)org
Subject: Re: 7.3 schedule
Date: 2002-04-12 20:24:48
Message-ID: 20020412162448.4d46d747.nconway@klamath.dyndns.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, 12 Apr 2002 12:21:04 -0400 (EDT)
"Bruce Momjian" <pgman(at)candle(dot)pha(dot)pa(dot)us> wrote:
> Tom Lane wrote:
> > A per-backend cache kept in local memory avoids all of these problems,
> > and I have seen no numbers to make me think that a shared plan cache
> > would achieve significantly more performance benefit than a local one.
>
> Certainly a shared cache would be good for apps that connect to issue a
> single query frequently. In such cases, there would be no local cache
> to use.

One problem with this kind of scenario is: what to do if the plan no
longer exists for some reason? (e.g. the code that was supposed to be
PREPARE-ing your statements failed to execute properly, or the cached
plan has been evicted from shared memory, or the database was restarted,
etc.) -- EXECUTE in and of itself won't have enough information to do
anything useful. We could perhaps provide a means for an application
to test for the existence of a cached plan (in which case the
application developer will need to add logic to their application
to re-prepare the query if necessary, which could get complicated).

Cheers,

Neil

--
Neil Conway <neilconway(at)rogers(dot)com>
PGP Key ID: DB3C29FC

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2002-04-12 21:25:31 Re: 7.3 schedule
Previous Message Jan Wieck 2002-04-12 17:57:28 Re: numeric/decimal docs bug?