Re: Pl/Perl function: Speed of the First time executing pl/perl function in connection;

Tom Lane wrote:
> Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
>
>> Tom Lane wrote:
>>
>>> The point here is to do the work at postmaster start time. You won't
>>> get a chance to find out whether both languages are defined in some
>>> database or other. (This is the same thing as the point about the
>>> UTF8 hack --- you can't tell if it's needed or not.)
>>>
>
>
>> w.r.t. UTF8, I guess we'll need a way of knowing if we're preloading or
>> not, and if so we'd need to skip the calls to GetDatabaseEncoding().
>>
>
> If you mean that you want to still do the UTF8 hack at backend start
> time, I think you might as well not bother with any of this. That hack
> in itself is slow enough to be 50% of the problem (presumably because
> it's loading some modules down in there somewhere). We need to arrange
> to either not do it at all or do it at preload.
>
>
>

I don't mean that we should do it at backend start even if we are
preloading. But you're not intending to make preloading compulsory, are
you?

The whole cost of loading that has been complained about is 1/10 of a
second per backend (or maybe more if you use both plperl and plperlu).
I'm fine with providing a preloading solution, but plenty of us who use
plperl from time to time are not disturbed by the current cost,
especially when it's used in web apps that use connection pooling, where
it disappears entirely in the noise.

Does preloading work at all in the BACKEND_EXEC case?

cheers

andrew