Re: PREPARE/EXECUTE across backends?

Поиск
Список
Период
Сортировка
От Karel Zak
Тема Re: PREPARE/EXECUTE across backends?
Дата
Msg-id 20031002081929.GG10129@zf.jcu.cz
обсуждение исходный текст
Ответ на Re: PREPARE/EXECUTE across backends?  (Neil Conway <neilc@samurai.com>)
Список pgsql-hackers
On Wed, Oct 01, 2003 at 09:01:23PM -0400, Neil Conway wrote:
> On Wed, 2003-10-01 at 20:25, Jingren Zhou wrote:
> > From the document, it seems that PREPARE/EXECUTE works only in the same 
> > session. I am wondering whether postgres can prepare a query (save the plan) 
> > for difference backends.
> 
> 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:

> That's all the reasons I can think of off the top of my head for doing
> things the way we do. However, I'm open to being convinced: if you think
> we should store prepared statements in shm, feel free to make a case for
> it.
I think  the current non-shared PREPARE/EXECUTE  is right solution. Theshared version  require define  new type  of
memory managment routineswhich is full compatible with the standard and abstract PostgreSQL mmgrtier.  I worked  on
thisbecause it was interesting  experiment and nowwe know that write something like this is possible :-)
 
I  think final  and right  solution are  persisten pre-forked  backendswhich know  to keep cached PREPARE/EXECUTE
stuff(and a lot  of othersthings) in  own memory. It's nice  and simple solution than  use sharedmemory.   Karel
 

-- Karel Zak  <zakkr@zf.jcu.cz>http://home.zf.jcu.cz/~zakkr/


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Greg Stark
Дата:
Сообщение: Re: ADD FOREIGN KEY
Следующее
От: Christopher Kings-Lynne
Дата:
Сообщение: Weird locking situation