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.