Scribd
Upload
2 views

Postgres_Configs

The document explains key PostgreSQL memory parameters: effective_cache_size, shared_buffers, and wal_buffers. Effective_cache_size informs the query planner about available memory for disk caching, while shared_buffers controls memory usage for caching frequently accessed data. Wal_buffers temporarily holds write-ahead log data, reducing disk I/O, and adjustments to these parameters can significantly impact query performance and system efficiency.

Uploaded by

MIMOUNI WAFAA
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
2 views

Postgres_Configs

The document explains key PostgreSQL memory parameters: effective_cache_size, shared_buffers, and wal_buffers. Effective_cache_size informs the query planner about available memory for disk caching, while shared_buffers controls memory usage for caching frequently accessed data. Wal_buffers temporarily holds write-ahead log data, reducing disk I/O, and adjustments to these parameters can significantly impact query performance and system efficiency.

Uploaded by

MIMOUNI WAFAA
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 3

effective_cache_size = 18GB

shared_buffers = 6GB

In PostgreSQL, the effective_cache_size parameter is an important setting that informs


the query planner about the amount of memory available for disk caching by the operating
system. It helps PostgreSQL estimate the cost of accessing data and optimize query execution
plans.

Explanation of effective_cache_size

 This parameter does not allocate memory; instead, it is a guideline for the planner to
understand how much memory the operating system is likely using for caching disk
files.
 A higher value indicates to the planner that more data can be cached, which may favor
index scans or other strategies that benefit from caching.

In the Example (effective_cache_size = 4GB)

 PostgreSQL assumes that 4 GB of memory is available for disk caching.


 This value should typically be set based on the size of the operating system's page
cache.

Default Value

 The default value varies depending on the PostgreSQL version and system, but it is
often set conservatively (e.g., 128MB or 4GB in modern systems).

How to Set the Value

1. Determine the approximate size of your server's available memory for disk caching.
2. A common guideline is to set effective_cache_size to 50-75% of the system's
total memory if your server is dedicated to PostgreSQL.

For example:

 If your system has 16 GB of RAM:


o A good starting value for effective_cache_size would be 12GB.

Impact on Query Performance

 Underestimated Value: If the value is set too low, the planner might avoid using
indexes or other cached data strategies, leading to slower query performance.
 Overestimated Value: If the value is set too high and the actual available cache is
much smaller, the planner's estimates may be inaccurate, potentially leading to
inefficient plans.
shared_buffers in PostgreSQL

 Purpose: The shared_buffers parameter controls how much memory PostgreSQL


will use for caching data in memory. This memory is shared between all database
connections, and it's where PostgreSQL stores frequently accessed data pages (table
rows, index pages, etc.) to avoid repeated disk access.
 Where It Fits: It is the most important memory setting within PostgreSQL for
performance because it dictates the size of the cache for data read from disk.

Default Value

 The default value of shared_buffers in PostgreSQL is typically 128MB on many


systems, but it can vary depending on the operating system and PostgreSQL version.

How shared_buffers Works

 PostgreSQL caches table and index data in the shared buffer pool, which reduces the
need for disk reads when the data is requested again.
 The larger the shared_buffers value, the more data can be cached in memory,
potentially improving performance by reducing I/O operations.

Typical Settings

 For a small system with limited memory, the default value may work well.
 For a dedicated PostgreSQL server with significant memory, it is generally
recommended to allocate between 25% and 40% of the total system memory to
shared_buffers.

Impact of shared_buffers

 Performance:
o Larger buffer pool: More data can be cached in memory, which results in
fewer disk I/O operations for frequently accessed data.
o Increased memory usage: More memory will be used by PostgreSQL, so
setting this value too high on a system with limited RAM can cause memory
pressure, potentially leading to swap usage or other resource constraints.
 Disk I/O Reduction: With a larger shared_buffers, frequently accessed data is
served from memory, which is faster than reading from disk.

Wal_buffers
The wal_buffers parameter in PostgreSQL determines the amount of shared memory
allocated for storing write-ahead log (WAL) data before it is written to disk. WAL buffers are
used to temporarily hold changes made to the database until they are flushed to the WAL
files.
Key Features of wal_buffers

 Purpose: Acts as a buffer for WAL data, reducing the frequency of disk I/O by
batching writes to the WAL files.
 Unit: The size is specified in kilobytes (kB).
 Default Value:
o Automatically set to 3% of shared_buffers or 16 MB, whichever is smaller
(starting from PostgreSQL 9.5).
o On earlier versions, the default is typically 512 kB.

When to Adjust wal_buffers

 High Write Workloads: Increase the size if your system frequently performs write-
intensive operations (e.g., bulk inserts, updates, or deletes).
 WAL Write Bottlenecks: If you notice excessive WAL writes or performance drops
related to WAL activity, a larger buffer may help.
 Monitoring Check: Look for WAL write metrics using tools like pg_stat_bgwriter
or by monitoring write-heavy queries.

You might also like