Re: shared_buffers/effective_cache_size on 96GB server - Mailing list pgsql-performance

From Josh Berkus
Subject Re: shared_buffers/effective_cache_size on 96GB server
Date
Msg-id 50770D57.9000409@agliodbs.com
Whole thread Raw
In response to Re: shared_buffers/effective_cache_size on 96GB server  (Jeff Janes <jeff.janes@gmail.com>)
Responses Re: shared_buffers/effective_cache_size on 96GB server  (Jeff Janes <jeff.janes@gmail.com>)
List pgsql-performance
Jeff,

> Does anyone see effective_cache_size make a difference anyway?  If so,
> in what circumstances?

E_C_S, together with random_page_cost, the table and index sizes, the
row estimates and the cpu_* costs, form an equation which estimates the
cost of doing various kinds of scans, particularly index scan vs. table
scan.  If you have an extremely small database (< shared_buffers) or a
very large database ( > 50X RAM ), the setting for E_C_S probably
doesn't matter, but in the fairly common case where some tables and
indexes fit in RAM and some don't, it matters.

> In my hands, queries for which effective_cache_size might come into
> play (for deciding between seq scan and index scan) are instead
> planned as bitmap scans.

You have a very unusual workload, or a very small database.


--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com


pgsql-performance by date:

Previous
From: Sergey Konoplev
Date:
Subject: Re: hash aggregation
Next
From: Sergio Gabriel Rodriguez
Date:
Subject: Re: problems with large objects dump