pgsql-server/ oc/src/sgml/runtime.sgml rc/back ...
От | momjian@postgresql.org (Bruce Momjian - CVS) |
---|---|
Тема | pgsql-server/ oc/src/sgml/runtime.sgml rc/back ... |
Дата | |
Msg-id | 20030320045145.0CC66475C3D@postgresql.org обсуждение исходный текст |
Список | pgsql-committers |
CVSROOT: /cvsroot Module name: pgsql-server Changes by: momjian@postgresql.org 03/03/19 23:51:44 Modified files: doc/src/sgml : runtime.sgml src/backend/postmaster: postmaster.c src/backend/utils/init: miscinit.c src/backend/utils/misc: guc.c postgresql.conf.sample src/include : miscadmin.h Log message: > I can see a couple possible downsides: (a) the library might have some > weird behavior across fork boundaries; (b) the additional memory space > that has to be duplicated into child processes will cost something per > child launch, even if the child never uses it. But these are only > arguments that it might not *always* be a prudent thing to do, not that > we shouldn't give the DBA the tool to do it if he wants. So fire away. Here is a patch for the above, including a documentation update. It creates a new GUC variable "preload_libraries", that accepts a list in the form: preload_libraries = '$libdir/mylib1:initfunc,$libdir/mylib2' If ":initfunc" is omitted or not found, no initialization function is executed, but the library is still preloaded. If "$libdir/mylib" isn't found, the postmaster refuses to start. In my testing with PL/R, it reduces the first call to a PL/R function (after connecting) from almost 2 seconds, down to about 8 ms. Joe Conway
В списке pgsql-committers по дате отправления: