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

From: "Oleg Serov" <serovov(at)gmail(dot)com>
To: "Andrew Dunstan" <andrew(at)dunslane(dot)net>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Pl/Perl function: Speed of the First time executing pl/perl function in connection;
Date: 2008-11-16 10:03:59
Message-ID: cec7c6df0811160203p31ec56c8ud2c7723b68ca891d@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hey, you are wrong, compile time is 1 ms, but not 100 ms, it hapens on
first plperl function call, it is perl init problem. not function
compilation.

2008/11/16 Oleg Serov <serovov(at)gmail(dot)com>:
> Why pl/pgsql doesn't have this effect ?
>
> 2008/11/16 Andrew Dunstan <andrew(at)dunslane(dot)net>:
>>
>>
>> Oleg Serov wrote:
>>>
>>> When perl function executes first time, it is too slowly, but if
>>> execute perl function(not function which executed first time) again it
>>> runs in 1000 times faster. Why ? how can i optimize it ?
>>> Configure shared_preload_libraries = '$libdir/plperl' or
>>> local_preload_libraries = '$libdir/plugins/plperl' does not help;
>>>
>>>
>>
>> The function is recompiled on the first call in each backend. (The same is
>> true of most PLs, BTW, it's not a perl-only problem.) There is no immediate
>> cure, unfortunately. Using pooled connections might help to mitigate the
>> effect.
>>
>> One might imagine providing for certain functions to be loaded on backend
>> startup, or even (where we aren't using BACKEND_EXEC) on postmaster start.
>> But that would be a new feature, and we are past feature freeze for the
>> upcoming release, so it's not going to happen any time soon.
>>
>> cheers
>>
>> andrrew
>>
>

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Meskes 2008-11-16 10:05:10 Re: pgsql: Enable script to generate preproc.y in build process.
Previous Message Fujii Masao 2008-11-16 10:02:26 Re: Synchronous replication patch v2