Re: PERSISTANT PREPARE (another point of view) - Mailing list pgsql-sql

From Milan Oparnica
Subject Re: PERSISTANT PREPARE (another point of view)
Date
Msg-id g5ve85$1gmr$1@news.hub.org
Whole thread Raw
In response to Re: PERSISTANT PREPARE (another point of view)  ("Pavel Stehule" <pavel.stehule@gmail.com>)
Responses Re: PERSISTANT PREPARE (another point of view)
List pgsql-sql
Pavel wrote:

> 
> try to write prototype and show advantages... 

Prototype of what, implementation into Postgre or just efficiency of 
PRESISTANT PREPARE idea ?

> ...but I see some disadvatage
> too. Mainly you have to manage some shared memory space for stored
> plans. It's not easy task - MySQL develepoers can talk. Implemenation
> on postgresql is little bit dificult - lot of structures that lives in
> processed memory have to be moved to shared memory.
> 

Is it solved in MySQL or they've just tried ?

We could have only PREP STATEMENT definition stored in shared memory 
(probably something like stored procedures), and it could be run in 
local processed memory. We could even assume only fetching data would be 
used through PREP STATEMENTS for start, and later introduce data 
modification. Is there some simplified PG algorithm we could use to 
understand the amount of work needed for introducing such feature to PG?

> This feature is nice, but question is - who do write it? 

With a little help form PG developers and good documentation perhaps I 
could put some programmers from my team on this job. They are mostly C++ 
programmers but we have Delphi and Java if needed.

> Actually this problem is solved from outside - with pooling.
> 

I'm very interested to learn more about this solution. Can you please 
send me details or some links where I could research this solution ?


Thank you for your reply Pavel.


pgsql-sql by date:

Previous
From: Stephan Szabo
Date:
Subject: Re: Whassup with this? (create table .... like ... fails)
Next
From: Milan Oparnica
Date:
Subject: Re: PERSISTANT PREPARE (another point of view)