| From: | Claudio Freire <klaussfreire(at)gmail(dot)com> |
|---|---|
| To: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com> |
| Cc: | Bruce Momjian <bruce(at)momjian(dot)us>, Strahinja Kustudić <strahinjak(at)nordeus(dot)com>, pgsql-performance(at)postgresql(dot)org |
| Subject: | Re: shared_buffers/effective_cache_size on 96GB server |
| Date: | 2012-10-10 22:37:10 |
| Message-ID: | CAGTBQpZvsm=pHf6=P=2w53ATbErA8Bb4idvwhw+DCJwkSL0=QA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
On Wed, Oct 10, 2012 at 7:33 PM, Jeff Janes <jeff(dot)janes(at)gmail(dot)com> wrote:
>> Well, the real question is whether, while traversing the index, if some
>> of the pages are going to be removed from the cache by other process
>> cache usage. effective_cache_size is not figuring the cache will remain
>> between queries.
>
> Does anyone see effective_cache_size make a difference anyway? If so,
> in what circumstances?
In my case, if I set it too high, I get impossibly suboptimal plans
when an index scan over millions of rows hits the disk way too often
way too randomly. The difference is minutes for a seqscan vs hours for
the index scan. In fact, I prefer setting it too low than too high.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Korisk | 2012-10-11 04:13:28 | Re: hash aggregation |
| Previous Message | Jeff Janes | 2012-10-10 22:33:11 | Re: shared_buffers/effective_cache_size on 96GB server |