Re: plpyhton

depends on the configuration implemented to enable caching capability for each type
*usually* fastest access can be achived by implementin a Procedure which loads into Procedure Cache
allowing consequent accesses to the Procedure 'in memory' (vs Disk I/O)

Martin Gainty
______________________________________________
Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité

Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen.

Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le destinataire prévu, nous te demandons avec bonté que pour satisfaire informez l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est interdite. Ce message sert à l'information seulement et n'aura pas n'importe quel effet légalement obligatoire. Étant donné que les email peuvent facilement être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité pour le contenu fourni.

 
> Date: Fri, 26 Nov 2010 09:04:42 -0700
> From: eggyknap@gmail.com
> To: shreeseva.learning@gmail.com
> CC: pgsql-admin@postgresql.org; pgsql-general@postgresql.org
> Subject: Re: [GENERAL] plpyhton

>
> On Fri, Nov 26, 2010 at 05:28:52PM +0530, c k wrote:
> > Thanks for your reply.
> > But if a database has 100+ connections then isn't loading any such
> > interpreter consumes more memory and requires more CPU? Does all PL
> > languages behave in the same fashion?
>
> If there are lots of connections, and each calls a plpython function (for
> example), then each will load a python interpreter, and certainly that could
> add up to serious memory usage. I can't speak for *every* PL; C functions
> don't load any special interpreter, for instance, and I don't think there's
> anything special you have to load to run SQL functions, beyond what gets
> loaded anyway.
>
> If you have problems with hundreds of connections using too much memory when
> each loads an interpreter, you ought to consider getting more memory, using a
> connection pooler, changing how you do things, or some combination of the
> above.
>
> --
> Joshua Tolley / eggyknap
> End Point Corporation
> http://www.endpoint.com