On Thu, Jun 26, 2014 at 2:14 AM, Rémi Cura <remi.cura@xxxxxxxxx> wrote: > Hey, > thanks for your answer ! > > Yep you are right, the function I would like to test are going to be called > a lot (100k times), so even 15 ms per call matters. > > I'm still a bit confused by a topic I found here : > http://stackoverflow.com/questions/15023080/how-are-import-statements-in-plpython-handled > The answer gives a trick to avoid importing each time, so somehow it must be > usefull. I'd want to see the benchmark before deciding that how useful it actually is.... Anyway, that seems to be about calling import over and over within the same connection, not between different connections, as is your issue. Also, I think that that suggestion is targeted at removing what is already a very minor overhead, which is importing the symbols from the module into the importer's namespace (or however you translate that into python speak). The slow part is loading the module in the first place (finding the shared objects, parsing the module's source code, gluing them together, etc.), not importing the python symbols. If you arrange to re-use connections, you will probably find no further optimization is needed. > On another internet page (can't find it anymore) somebody mentioned this > module loading at server startup, one way or another, but gave no precision. > It seems that the "plpy" python module get loaded by default, would'nt it be > possible to hack this module to add other import inside it? I just thought your question looked lonely and that I'd tell you what I learned about plperl in case it helped. There may be a way to do about the same thing in plpython, but if so it doesn't seem to be documented, or analogous to the way plperl does it. I'm afraid that exhausts my knowledge of plpython. I don't see any files that suggests there is a user-editable plpy.py module. If you are willing to monkey around with C and recompiling, you could probably make it happen somehow, though. Cheers, Jeff
