Neil Conway wrote: > On Fri, 12 Apr 2002 12:21:04 -0400 (EDT) > "Bruce Momjian" <[EMAIL PROTECTED]> 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).
Oh, are you thinking that one backend would do the PREPARE and another one the EXECUTE? I can't see that working at all. I thought there would some way to quickly test if the submitted query was in the cache, but maybe that is too much of a performance penalty to be worth it. -- Bruce Momjian | http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026 ---------------------------(end of broadcast)--------------------------- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly