Database Reference
In-Depth Information
In many cases useful modules may not have full packaging. In these cases you may need
to install the module manually. This isn't very hard and is a useful exercise to help you
understand what happens.
Each module will have different installation requirements. There are generally two aspects
to installing a module. They are as follows:
F
Installing the SQL objects for the module
F
Installing the dynamic load libraries for the module
Most of the more useful modules require you to handle both of the aforementioned aspects.
There are a couple of examples, such as AutoExplain, that only has dynamic load libraries.
F
Build the libraries
Follow instructions for that module
F
Install the library where the server can find it:
shared_preload_libraries = '$libdir/modlib'
Create the database objects
psql -d dbname -f SHAREDIR/contrib/module.sql
How it works...
PostgreSQL can dynamically load libraries in the following three ways:
F
By using the explicit
LOAD
command in a session
F
By using
shared_preload_libraries
parameter in
postgresql.conf
at server start
F
At session start, using
local_preload_libraries
parameter for a specific
user, as set using ALTER ROLE
PostgreSQL functions and objects can reference code in these libraries, allowing extensions
to be bound tightly into the running server process. The tight binding makes this method
suitable for use even in very high-performance applications, and there's no significant
difference between additional supplied features and native ones.
Running server in power saving mode
Power consumption is a hot topic. Everybody is looking for ways to do their bit
for the environment. The same is true for PostgreSQL users.
