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 по дате отправления: