PostgreSQL is expected to have both its own dedicated memory (shared_buffers)
as well as utilize the filesystem cache. In some cases, when making
decisions like whether it is efficient to use an index or not, the
database compares sizes it computes against the effective sum of all
these caches; that's what it expects to find in effective_cache_size.
The same rough rule of thumb that would put shared_buffers at 25 percent of system memory would set effective_cache_size to between 50 and 75 percent of RAM. To get a more accurate estimate, first observe the size of the filesystem cache:
- UNIX-like systems: Add the free and cached numbers shown by the free or top commands to estimate the filesystem cache size
- Windows: Use the Windows Task Manager's Performance tab and look at the System Cache size
effective_cache_size does not allocate any memory. It's strictly used as input on how queries are executed, and a rough estimate is sufficient for most purposes. However, if you set this value much too high, actually executing the resulting queries may result in both the database and OS cache being disrupted by reading in the large number of blocks required to satisfy the query believed to fit easily in RAM.
It's rare you'll ever see this parameter tuned on a per-client basis, even though it is possible.
Per-client settings Parameter
While all of the settings in this section can be adjusted per client, you'll still want good starting settings for these parameters in the main configuration file. Individual clients that need values outside the standard can always do so using the SET command within their session.
