По моему тут этот вопрос никто глубоко не знает - поэтому и гадают..
Ответ по моему мнению нужно искать заслав вопрос в конфу разработчиков на postgresql.org

Цитаты:
2.1.1 Общий буфер сервера: shared_buffers
PostgreSQL не читает данные напрямую с диска и не пишет их сразу на диск.
Данные загружаются в общий буфер сервера, находящийся в разделяемой па-
мяти, серверные процессы читают и пишут блоки в этом буфере, а затем уже
изменения сбрасываются на диск.
Если процессу нужен доступ к таблице, то он сначала ищет нужные блоки в
общем буфере. Если блоки присутствуют, то он может продолжать работу, если
нет делается системный вызов для их загрузки. Загружаться блоки могут
как из файлового кэша ОС, так и с диска, и эта операция может оказаться
весьма _дорогойї.
Если объ_м буфера недостаточен для хранения часто используемых рабочих
данных, то они будут постоянно писаться и читаться из кэша ОС или с диска,
что крайне отрицательно скажется на производительности.
Объ_м зада_тся параметром shared_buffers в файле postgresql.conf.
Единица измерения параметра блоки величиной 8 кБ. По умолчанию зна-
чение параметра составляет 641, что соответствует 512 кБ памяти. Это весьма
мало, и для полноценной работы значение параметра следует увеличить.
В то же время не следует устанавливать это значение слишком большим:
PostgreSQL полагается на то, что операционная система кэширует файлы (см.
пункт 2.4.1), и не старается дублировать эту работу. Кроме того, чем больше
памяти будет отдано под буфер, тем меньше останется операционной системе
и другим приложениям, что может привести к своппингу.
В качестве начальных значений можете попробовать следующие:
Начните с 4 МБ (512) для рабочей станции
Средний объ_м данных и 256-512 МБ доступной памяти: 16-32 МБ (2048-
4096)
Большой объ_м данных и 1-4 ГБ доступной памяти: 64-256 МБ (8192-
32768)
Для тонкой настройки параметра установите для него большое значение и поте-
стируйте базу при обычной нагрузке. Проверяйте использование разделяемой
памяти при помощи ipcs или других утилит. Рекомендуемое значение парамет-
ра будет примерно в 1,2-2 раза больше, чем максимум использованной памяти.
Обратите внимание, что память под буфер выделятся при запуске сервера, и
е_ объ_м при работе не изменяется. Учтите также, что настройки ядра операци-
онной системы могут не дать вам выделить большой объ_м памяти. В руковод-
стве администратора PostgreSQL описано, как можно изменить эти настройки:
http://developer.postgresql.org/docs/postgres/kernel-resources.html

2.4 Прочие настройки
2.4.1 Оценка объ_ма кэша ОС: effective_cache_size
Этот параметр сообщает PostgreSQL примерный объ_м файлового кэша опе-
рационной системы, оптимизатор использует эту оценку для построения плана
запроса.
Объ_м зада_тся параметром effective_cache_size в postgresql.conf.
Единица измерения блоки величиной 8 кБ. По умолчанию значение пара-
метра составляет 1000.
Пусть в вашем компьютере 1,5 ГБ памяти, параметр shared_buffers уста-
новлен в 32 МБ, а параметр effective_cache_size в 800 МБ. Если запросу
нужно 700 МБ данных, то PostgreSQL оценит, что все нужные данные уже
есть в памяти и выберет более агрессивный план с использованием индексов
и merge joins. Но если effective_cache_size будет всего 200 МБ, то оптими-
затор вполне может выбрать более эффективный для дисковой системы план,
включающий полный просмотр таблицы.
В качестве начального значения можете использовать 25-50% доступной5
памяти.
2.4.2 Сбор статистики
default_statistics_target зада_т объ_м по умолчанию статистики, собира-
емой командой ANALYZE (см. пункт 3.1.2). Увеличение параметра за-
ставит эту команду работать дольше, но может позволить оптимизато-
ру строить более быстрые планы, используя полученные дополнительные
данные. Объ_м статистики для конкретного поля может быть задан ко-
мандой ALTER TABLE . . . SET STATISTICS.
5т.е. не занятой операционной системой и приложениями
7
У PostgreSQL также есть специальная подсистема сборщик статистики,
которая в реальном времени собирает данные об активности сервера. Эта под-
система контролируется следующими параметрами, принимающими значения
true/false:
stats_start_collector включать ли сбор статистики. По умолчанию вклю-
ч_н, отключайте, только если статистика вас совершенно не интересует.
stats_reset_on_server_start обнулять ли статистику при перезапуске сер-
вера. По умолчанию обнулять.
stats_command_string передавать ли сборщику статистики информацию
о текущей выполняемой команде и времени начала е_ выполнения. По
умолчанию эта возможность отключена. Следует отметить, что эта ин-
формация будет доступна только привилегированным пользователям и
пользователям, от лица которых запущены команды, так что проблем с
безопасностью быть не должно.
stats_row_level, stats_block_level собирать ли информацию об активно-
сти на уровне записей и блоков соответственно. По умолчанию сбор от-
ключ_н.
Данные, полученные сборщиком статистики, доступны через специальные си-
стемные представления. При установках по умолчанию собирается очень мало
информации, рекомендуется включить все возможности: дополнительная на-
грузка будет невелика, в то время как полученные данные позволят оптимизи-
ровать использование индексов (см. пункт 3.2.2).