Re: 7.3 schedule
От | Neil Conway |
---|---|
Тема | Re: 7.3 schedule |
Дата | |
Msg-id | 20020412162448.4d46d747.nconway@klamath.dyndns.org обсуждение исходный текст |
Ответ на | Re: 7.3 schedule (Bruce Momjian <pgman@candle.pha.pa.us>) |
Ответы |
Re: 7.3 schedule
|
Список | pgsql-hackers |
On Fri, 12 Apr 2002 12:21:04 -0400 (EDT) "Bruce Momjian" <pgman@candle.pha.pa.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@rogers.com> PGP Key ID: DB3C29FC
В списке pgsql-hackers по дате отправления: