On Thu, Jun 26, 2014 at 2:14 AM, Rémi Cura <remi.cura@gmail.com> 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
