effective_cache_size is one of PostgreSQL's most misunderstood parameters. It does not allocate memory, reserve RAM, or change runtime behavior — it is purely a hint to the query planner estimating how much total cache (shared_buffers plus OS page cache) is available. The planner uses this value via the Mackert-Lohman formula to estimate physical I/O cost for index scans: a high value makes index scans and nested-loop joins look cheaper, while a low value pushes the planner toward sequential scans and hash joins. The recommended setting is 50–75% of total system RAM when PostgreSQL is the primary workload, always larger than shared_buffers. Setting it too conservatively is the common failure mode, causing the planner to overprice index scans against data that is actually in memory.

5m read timeFrom postgr.es
Post cover image
Table of contents
What it is notWhat it actually doesSetting it
308 Impressions