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

From Jeff Janes
Subject Re: shared_buffers/effective_cache_size on 96GB server
Date
Msg-id CAMkU=1yBJN13z+p1mQ5JczDdqq40TwfKNRNe-07Sb+HSL7pKjA@mail.gmail.com
Whole thread Raw
In response to Re: shared_buffers/effective_cache_size on 96GB server  (Bruce Momjian <bruce@momjian.us>)
Responses Re: shared_buffers/effective_cache_size on 96GB server
Re: shared_buffers/effective_cache_size on 96GB server
List pgsql-performance
On Wed, Oct 10, 2012 at 2:03 PM, Bruce Momjian <bruce@momjian.us> wrote:
> On Wed, Oct 10, 2012 at 10:12:51PM +0200, Strahinja Kustudić wrote:

>> @Claudio So you are basically saying that if I have set effective_cache_size to
>> 10GB and I have 10 concurrent processes which are using 10 different indices
>> which are for example 2GB, it would be better to set the effective_cache size
>> to 1GB? Since if I leave it at 10GB each running process query planner will
>> think the whole index is in cache and that won't be true? Did I get that right?
>
> 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 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.

Cheers,

Jeff


pgsql-performance by date:

Previous
From: Claudio Freire
Date:
Subject: Re: shared_buffers/effective_cache_size on 96GB server
Next
From: Claudio Freire
Date:
Subject: Re: shared_buffers/effective_cache_size on 96GB server