Tom Lane wrote:
It seems entirely sensible to me for the postmaster to choke on invalid
settings in postgresql.conf. Better than failing to mention the problem
at all, anyway.
2) do you want a patch that exports plperl_init_all() (and I guess
similar init functions in pltcl and plpython)?
Yeah, I
Joe Conway <[EMAIL PROTECTED]> writes:
> My reasoning at the time was that library preloading shouldn't prevent
> the postmaster from starting, even if it is unsuccessful, but now I
> wonder if that was a good idea.
It seems entirely sensible to me for the postmaster to choke on invalid
settings
Tom Lane wrote:
Joe Conway <[EMAIL PROTECTED]> writes:
I tried that after I posted, but only saw roughly 30% improvement (which
is consistent with my earlier tests IIRC). Not bad, but this still left
plperl initial call at ~40 msec versus plpgsql at ~4 msec.
Hm. And the first call to a plpgsql f
Joe Conway <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> It might help if libperl were to be preloaded into the postmaster in the
>> way you created ...
> I tried that after I posted, but only saw roughly 30% improvement (which
> is consistent with my earlier tests IIRC). Not bad, but this st
Tom Lane wrote:
Presumably, the 50 msec difference represents the time to load up the
perl library and initialize a perl interpreter.
It might help if libperl were to be preloaded into the postmaster in the
way you created ...
I tried that after I posted, but only saw roughly 30% improvement (whi
Joe Conway <[EMAIL PROTECTED]> writes:
> So based on this simple test, I'd say that if you only run the function
> once per connect, use plpgsql, but if you run the function many times
> during one backend session, use perl.
Presumably, the 50 msec difference represents the time to load up the
p
