Re: PERSISTANT PREPARE (another point of view)

Hello

2008/7/16 Milan Oparnica <milan(dot)opa(at)gmail(dot)com>:
> Milan Oparnica wrote:
>>
>> It's simply to complicated to return recordsets through server-side stored
>> procedures. They are obviously designed to do complex data manipulation,
>> returning few output variables informing the caller about final results.
>> Returning records through sets of user-defined-types is memory and
>> performance waste (please see my previous post as reply to Steve for more
>> details). Plus it's hard to maintain and make improvements to such a system.
>> I hate to see 800 user types made for every query we made as stored
>> procedure.
>
> Is this topic completely out of scope in Postgre ?
> If I'm missing something too obvious or too important, please let me know
> what.
>
> I run over and over through internet and Postgre documentation and still
> found nothing.
>

try to write prototype and show advantages. I am able to undestand
advantages of persistent prep. stamenents, 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.

This feature is nice, but question is - who do write it? Actually this
problem is solved from outside - with pooling.

Regards
Pavel Stehule

> Is there a better place to communicate with Postgre developers ?
>
> Sincerely,
>
> Milan Oparnica
>
> --
> Sent via pgsql-sql mailing list (pgsql-sql(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-sql
>