Sets the amount of memory the database server uses for
shared memory buffers. The default is typically 32
megabytes (32MB), but might be
less if your kernel settings will not support it (as
determined during initdb). This setting must be at
least 128 kilobytes. (Non-default values of BLCKSZ change the minimum.) However,
settings significantly higher than the minimum are
usually needed for good performance. This parameter can
only be set at server start.

If you have a dedicated database server with 1GB or
more of RAM, a reasonable starting value for shared_buffers is 25% of the memory in
your system. There are some workloads where even large
settings for shared_buffers are
effective, but because PostgreSQL also relies on the
operating system cache, it is unlikely that an allocation
of more than 40% of RAM to shared_buffers will work better than a
smaller amount. Larger settings for shared_buffers usually require a
corresponding increase in checkpoint_segments, in order to spread
out the process of writing large quantities of new or
changed data over a longer period of time.

On systems with less than 1GB of RAM, a smaller
percentage of RAM is appropriate, so as to leave adequate
space for the operating system. Also, on Windows, large
values for shared_buffers aren't
as effective. You may find better results keeping the
setting relatively low and using the operating system
cache more instead. The useful range for shared_buffers on Windows systems is
generally from 64MB to 512MB.

Increasing this parameter might cause PostgreSQL to request more
System V shared memory
than your operating system's default configuration
allows. See Section 17.4.1 for
information on how to adjust those parameters, if
necessary.

temp_buffers (integer)

Sets the maximum number of temporary buffers used by
each database session. These are session-local buffers
used only for access to temporary tables. The default is
eight megabytes (8MB). The
setting can be changed within individual sessions, but
only before the first use of temporary tables within the
session; subsequent attempts to change the value will
have no effect on that session.

A session will allocate temporary buffers as needed up
to the limit given by temp_buffers. The cost of setting a large
value in sessions that do not actually need many
temporary buffers is only a buffer descriptor, or about
64 bytes, per increment in temp_buffers. However if a buffer is
actually used an additional 8192 bytes will be consumed
for it (or in general, BLCKSZ
bytes).

max_prepared_transactions (integer)

Sets the maximum number of transactions that can be in
the "prepared" state
simultaneously (see PREPARE TRANSACTION).
Setting this parameter to zero (which is the default)
disables the prepared-transaction feature. This parameter
can only be set at server start.

If you are not planning to use prepared transactions,
this parameter should be set to zero to prevent
accidental creation of prepared transactions. If you are
using prepared transactions, you will probably want
max_prepared_transactions to be
at least as large as max_connections,
so that every session can have a prepared transaction
pending.

Increasing this parameter might cause PostgreSQL to request more
System V shared memory
than your operating system's default configuration
allows. See Section 17.4.1 for
information on how to adjust those parameters, if
necessary.

When running a standby server, you must set this
parameter to the same or higher value than on the master
server. Otherwise, queries will not be allowed in the
standby server.

work_mem (integer)

Specifies the amount of memory to be used by internal
sort operations and hash tables before writing to
temporary disk files. The value defaults to one megabyte
(1MB). Note that for a complex
query, several sort or hash operations might be running
in parallel; each operation will be allowed to use as
much memory as this value specifies before it starts to
write data into temporary files. Also, several running
sessions could be doing such operations concurrently.
Therefore, the total memory used could be many times the
value of work_mem; it is
necessary to keep this fact in mind when choosing the
value. Sort operations are used for ORDER BY, DISTINCT, and merge joins. Hash tables are
used in hash joins, hash-based aggregation, and
hash-based processing of IN
subqueries.

maintenance_work_mem (integer)

Specifies the maximum amount of memory to be used by
maintenance operations, such as VACUUM, CREATE
INDEX, and ALTER TABLE ADD
FOREIGN KEY. It defaults to 16 megabytes (16MB). Since only one of these operations
can be executed at a time by a database session, and an
installation normally doesn't have many of them running
concurrently, it's safe to set this value significantly
larger than work_mem. Larger
settings might improve performance for vacuuming and for
restoring database dumps.

Note that when autovacuum runs, up to
autovacuum_max_workers times this memory may be
allocated, so be careful not to set the default value too
high.

max_stack_depth (integer)

Specifies the maximum safe depth of the server's
execution stack. The ideal setting for this parameter is
the actual stack size limit enforced by the kernel (as
set by ulimit -s or local
equivalent), less a safety margin of a megabyte or so.
The safety margin is needed because the stack depth is
not checked in every routine in the server, but only in
key potentially-recursive routines such as expression
evaluation. The default setting is two megabytes
(2MB), which is conservatively
small and unlikely to risk crashes. However, it might be
too small to allow execution of complex functions. Only
superusers can change this setting.

Setting max_stack_depth
higher than the actual kernel limit will mean that a
runaway recursive function can crash an individual
backend process. On platforms where PostgreSQL can determine the kernel
limit, the server will not allow this variable to be set
to an unsafe value. However, not all platforms provide
the information, so caution is recommended in selecting a
value.

Specifies the maximum amount of disk space that a
session can use for temporary files, such as sort and
hash temporary files, or the storage file for a held
cursor. A transaction attempting to exceed this limit
will be cancelled. The value is specified in kilobytes,
and -1 (the default) means no
limit. Only superusers can change this setting.

This setting constrains the total space used at any
instant by all temporary files used by a given
PostgreSQL session. It
should be noted that disk space used for explicit
temporary tables, as opposed to temporary files used
behind-the-scenes in query execution, does not count against this
limit.

Sets the maximum number of simultaneously open files
allowed to each server subprocess. The default is one
thousand files. If the kernel is enforcing a safe
per-process limit, you don't need to worry about this
setting. But on some platforms (notably, most BSD
systems), the kernel will allow individual processes to
open many more files than the system can actually support
if many processes all try to open that many files. If you
find yourself seeing "Too many open
files" failures, try reducing this setting. This
parameter can only be set at server start.

shared_preload_libraries (string)

This variable specifies one or more shared libraries
to be preloaded at server start. For example, '$libdir/mylib' would cause mylib.so (or on some platforms, mylib.sl) to be preloaded from the
installation's standard library directory. All library
names are converted to lower case unless double-quoted.
If more than one library is to be loaded, separate their
names with commas. This parameter can only be set at
server start.

PostgreSQL procedural
language libraries can be preloaded in this way,
typically by using the syntax '$libdir/plXXX' where XXX is pgsql,
perl, tcl, or python.

By preloading a shared library, the library startup
time is avoided when the library is first used. However,
the time to start each new server process might increase
slightly, even if that process never uses the library. So
this parameter is recommended only for libraries that
will be used in most sessions.

Note: On Windows hosts, preloading a
library at server start will not reduce the time
required to start each new server process; each
server process will re-load all preload libraries.
However, shared_preload_libraries is still
useful on Windows hosts because some shared libraries
may need to perform certain operations that only take
place at postmaster start (for example, a shared
library may need to reserve lightweight locks or
shared memory and you can't do that after the
postmaster has started).

If a specified library is not found, the server will
fail to start.

Every PostgreSQL-supported library has a "magic block" that is checked to guarantee
compatibility. For this reason, non-PostgreSQL libraries
cannot be loaded in this way.

During the execution of VACUUM
and ANALYZE commands, the system
maintains an internal counter that keeps track of the estimated
cost of the various I/O operations that are performed. When the
accumulated cost reaches a limit (specified by vacuum_cost_limit), the process performing the
operation will sleep for a short period of time, as specified
by vacuum_cost_delay. Then it will
reset the counter and continue execution.

The intent of this feature is to allow administrators to
reduce the I/O impact of these commands on concurrent database
activity. There are many situations where it is not important
that maintenance commands like VACUUM
and ANALYZE finish quickly; however,
it is usually very important that these commands do not
significantly interfere with the ability of the system to
perform other database operations. Cost-based vacuum delay
provides a way for administrators to achieve this.

This feature is disabled by default for manually issued
VACUUM commands. To enable it, set the
vacuum_cost_delay variable to a
nonzero value.

vacuum_cost_delay (integer)

The length of time, in milliseconds, that the process
will sleep when the cost limit has been exceeded. The
default value is zero, which disables the cost-based
vacuum delay feature. Positive values enable cost-based
vacuuming. Note that on many systems, the effective
resolution of sleep delays is 10 milliseconds; setting
vacuum_cost_delay to a value
that is not a multiple of 10 might have the same results
as setting it to the next higher multiple of 10.

When using cost-based vacuuming, appropriate values
for vacuum_cost_delay are
usually quite small, perhaps 10 or 20 milliseconds.
Adjusting vacuum's resource consumption is best done by
changing the other vacuum cost parameters.

vacuum_cost_page_hit (integer)

The estimated cost for vacuuming a buffer found in the
shared buffer cache. It represents the cost to lock the
buffer pool, lookup the shared hash table and scan the
content of the page. The default value is one.

vacuum_cost_page_miss (integer)

The estimated cost for vacuuming a buffer that has to
be read from disk. This represents the effort to lock the
buffer pool, lookup the shared hash table, read the
desired block in from the disk and scan its content. The
default value is 10.

vacuum_cost_page_dirty (integer)

The estimated cost charged when vacuum modifies a
block that was previously clean. It represents the extra
I/O required to flush the dirty block out to disk again.
The default value is 20.

vacuum_cost_limit (integer)

The accumulated cost that will cause the vacuuming
process to sleep. The default value is 200.

Note: There are certain operations that hold
critical locks and should therefore complete as quickly as
possible. Cost-based vacuum delays do not occur during such
operations. Therefore it is possible that the cost
accumulates far higher than the specified limit. To avoid
uselessly long delays in such cases, the actual delay is
calculated as vacuum_cost_delay *
accumulated_balance / vacuum_cost_limit with a maximum of
vacuum_cost_delay * 4.

There is a separate server process called the background writer, whose function is to issue
writes of "dirty" (new or modified)
shared buffers. It writes shared buffers so server processes
handling user queries seldom or never need to wait for a write
to occur. However, the background writer does cause a net
overall increase in I/O load, because while a
repeatedly-dirtied page might otherwise be written only once
per checkpoint interval, the background writer might write it
several times as it is dirtied in the same interval. The
parameters discussed in this subsection can be used to tune the
behavior for local needs.

bgwriter_delay (integer)

Specifies the delay between activity rounds for the
background writer. In each round the writer issues writes
for some number of dirty buffers (controllable by the
following parameters). It then sleeps for bgwriter_delay milliseconds, and repeats.
When there are no dirty buffers in the buffer pool,
though, it goes into a longer sleep regardless of
bgwriter_delay. The default
value is 200 milliseconds (200ms). Note that on many systems, the
effective resolution of sleep delays is 10 milliseconds;
setting bgwriter_delay to a
value that is not a multiple of 10 might have the same
results as setting it to the next higher multiple of 10.
This parameter can only be set in the postgresql.conf file or on the server
command line.

bgwriter_lru_maxpages (integer)

In each round, no more than this many buffers will be
written by the background writer. Setting this to zero
disables background writing. (Note that checkpoints,
which are managed by a separate, dedicated auxiliary
process, are unaffected.) The default value is 100
buffers. This parameter can only be set in the postgresql.conf file or on the server
command line.

bgwriter_lru_multiplier (floating point)

The number of dirty buffers written in each round is
based on the number of new buffers that have been needed
by server processes during recent rounds. The average
recent need is multiplied by bgwriter_lru_multiplier to arrive at an
estimate of the number of buffers that will be needed
during the next round. Dirty buffers are written until
there are that many clean, reusable buffers available.
(However, no more than bgwriter_lru_maxpages buffers will be
written per round.) Thus, a setting of 1.0 represents a
"just in time" policy of
writing exactly the number of buffers predicted to be
needed. Larger values provide some cushion against spikes
in demand, while smaller values intentionally leave
writes to be done by server processes. The default is
2.0. This parameter can only be set in the postgresql.conf file or on the server
command line.

Smaller values of bgwriter_lru_maxpages and bgwriter_lru_multiplier reduce the extra I/O
load caused by the background writer, but make it more likely
that server processes will have to issue writes for themselves,
delaying interactive queries.

Sets the number of concurrent disk I/O operations that
PostgreSQL expects can
be executed simultaneously. Raising this value will
increase the number of I/O operations that any individual
PostgreSQL session
attempts to initiate in parallel. The allowed range is 1
to 1000, or zero to disable issuance of asynchronous I/O
requests. Currently, this setting only affects bitmap
heap scans.

A good starting point for this setting is the number
of separate drives comprising a RAID 0 stripe or RAID 1
mirror being used for the database. (For RAID 5 the
parity drive should not be counted.) However, if the
database is often busy with multiple queries issued in
concurrent sessions, lower values may be sufficient to
keep the disk array busy. A value higher than needed to
keep the disks busy will only result in extra CPU
overhead.

For more exotic systems, such as memory-based storage
or a RAID array that is limited by bus bandwidth, the
correct value might be the number of I/O paths available.
Some experimentation may be needed to find the best
value.

Asynchronous I/O depends on an effective posix_fadvise function, which some
operating systems lack. If the function is not present
then setting this parameter to anything but zero will
result in an error. On some operating systems (e.g.,
Solaris), the function is present but does not actually
do anything.

Submit correction

If you see anything in the documentation that is not correct, does not match
your experience with the particular feature or requires further clarification,
please use
this form
to report a documentation issue.