Re: Pl/Perl function: Speed of the First time executing pl/perl function in connection;
От | Oleg Serov |
---|---|
Тема | Re: Pl/Perl function: Speed of the First time executing pl/perl function in connection; |
Дата | |
Msg-id | cec7c6df0811160203p31ec56c8ud2c7723b68ca891d@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Pl/Perl function: Speed of the First time executing pl/perl function in connection; ("Oleg Serov" <serovov@gmail.com>) |
Ответы |
Re: Pl/Perl function: Speed of the First time executing
pl/perl function in connection;
|
Список | 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@gmail.com>: > Why pl/pgsql doesn't have this effect ? > > 2008/11/16 Andrew Dunstan <andrew@dunslane.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 >> >
В списке pgsql-hackers по дате отправления: