Memory Parameters in PostgreSQL

shared_buffers (integer):

• 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. 


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 the server start.
• If you are not planning to use prepared transactions, this parameter should be set to zero to prevent the 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.
• 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 on 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 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 the 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.