> I can see a couple possible downsides: (a) the library might have some
Bruce Momjian <bruce@momjian.us>
> 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
Files
| Path | Change | +/− |
|---|---|---|
| doc/src/sgml/runtime.sgml | modified | +30 −1 |
| src/backend/postmaster/postmaster.c | modified | +10 −1 |
| src/backend/utils/init/miscinit.c | modified | +90 −1 |
| src/backend/utils/misc/guc.c | modified | +8 −1 |
| src/backend/utils/misc/postgresql.conf.sample | modified | +1 −0 |
| src/include/miscadmin.h | modified | +2 −1 |