Re: Pl/Perl function: Speed of the First time executing pl/perl function in connection;
| От | Andrew Dunstan | 
|---|---|
| Тема | Re: Pl/Perl function: Speed of the First time executing pl/perl function in connection; | 
| Дата | |
| Msg-id | 49218955.6070209@dunslane.net обсуждение исходный текст | 
| Ответ на | Re: Pl/Perl function: Speed of the First time executing pl/perl function in connection; (Tom Lane <tgl@sss.pgh.pa.us>) | 
| Ответы | Re: Pl/Perl function: Speed of the First time executing pl/perl function in connection; | 
| Список | pgsql-hackers | 
Tom Lane wrote: > Andrew Dunstan <andrew@dunslane.net> writes: > >> Tom Lane wrote: >> >>> So about the only real answer is going to be preloading. It seems worth >>> considering that on machines where can_run_two is true, we should just >>> go ahead and initialize both interps at _PG_init time, so as to allow >>> the "require Safe" overhead to be bought back by preloading. >>> > > >> Even if only one language is defined? >> > > 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(). I assume this will all happen in the 8.5 dev cycle (or later). cheers andrew
В списке pgsql-hackers по дате отправления: