ThamerlanУдивляет, что сначала одни советуют shared_buffers не выставлять намного более 20000 buffers (~160 МБ), ибо производительность будет падать, а тут те на ... 3 ГБ.

Производительность действительно падает при большом количестве разделяемой памяти, но 160 MB -- этой рекомендации уже 4 года и она устарела. В реальной жизни нужен некоторый разумный компромисс между потерями CPU из-за больших циклов по shared buffers и тем, что у вас много активных данных находится "близко" к PostgreSQL. На машинах с 4-8 GB RAM объем разделяемой памяти вполне может составлять 1GB. Дальше ее увеличивать нужно только аккуратно замеряя эффект на производительность и в большинстве случаев она только ухудшается. Если памяти много больше 8GB -- вполне можно пытаться использовать настройки и в 3GB.

А вообще этой новости больше месяца: http://postgresmen.ru/news/view/44

Andrey Daeron Winnipuh Andrey Daeronага , особенно прикольно что на железе:
Memory (MB): 16376

Честно говоря я не совсем понял чему тут сильно радоваться, кроме того факта что PG засветился на SPEC.

а почему 16 ГБ - прикольно?
А как при этом эфективный кеш сайз может быть 40 гигов?

effective_cache_size не является размером памяти, которую каким-то образом аллоцирует PostgreSQL. Эта настройка нужна только для планировщика запросов и входит параметром в расчет стоимости seqscan vs. indexscan -- подробнее см. док-ию. Поэтому ничего не сломается, если ее поставить хоть в 1TB -- просто PostgreSQL будет считать, что все данные сидят в дисковом кеше ОС и random access к ним является быстрой операцией -- следовательно, в планах будут преобладать indexscan-ы.

Thamerlan
А не лучше ли тогда поиграться с random_page_cost, cpu_tuple_cost, cpu_index_tuple_cost, cpu_operator_cost?

Разумеется, это правильнее. Дальше нужно разбираться, почему в тесте был использован такой несколько странный способ. Но все же объективно это никакая не "дыра" и назначение параметра вполне подробно описано в документации. Вполне возможно, что авторы варьировали effective_cache_size просто потому, что так быстрее достигается нужный результат в планнере и не нужно долго подбирать многочисленные параметры *_cost.