Re: PREPARE/EXECUTE across backends?
От | Tom Lane |
---|---|
Тема | Re: PREPARE/EXECUTE across backends? |
Дата | |
Msg-id | 11709.1065062626@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: PREPARE/EXECUTE across backends? (Neil Conway <neilc@samurai.com>) |
Ответы |
Re: PREPARE/EXECUTE across backends?
|
Список | pgsql-hackers |
Neil Conway <neilc@samurai.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 exists. 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
В списке pgsql-hackers по дате отправления: