Re: shared_buffers/effective_cache_size on 96GB server

Поиск
Список
Период
Сортировка
От Jeff Janes
Тема Re: shared_buffers/effective_cache_size on 96GB server
Дата
Msg-id CAMkU=1yBJN13z+p1mQ5JczDdqq40TwfKNRNe-07Sb+HSL7pKjA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: shared_buffers/effective_cache_size on 96GB server  (Bruce Momjian <bruce@momjian.us>)
Ответы Re: shared_buffers/effective_cache_size on 96GB server  (Claudio Freire <klaussfreire@gmail.com>)
Re: shared_buffers/effective_cache_size on 96GB server  (Josh Berkus <josh@agliodbs.com>)
Список 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 по дате отправления:

Предыдущее
От: Claudio Freire
Дата:
Сообщение: Re: shared_buffers/effective_cache_size on 96GB server
Следующее
От: Claudio Freire
Дата:
Сообщение: Re: shared_buffers/effective_cache_size on 96GB server