Павел Назаров

1. Включить slow-log в PostgreSQL.
2. Посмотреть топ самых медленных и частых запросов, EXPLAIN, посмотреть, может индексов не хватает, может что хитрее.
3. Клиенты могут отваливаться, когда все коннекшны к постгресу забиты. Других вариантов не вижу - смотреть логи приложения, вообще-то должно что-то писать в этот момент.

PS. На уровне приложения оптимизация - должна выполнять более оптимальные запросы.

Вообще постгри любит кэшировать индексы в оперативную память, и поэтому чем больше её отдать, тем лучше.
А разницу между запросами смотрите нормальным EXPLAIN, с буферами - наверняка первый запрос делал IO, а второй использовал cached buffers.

Общий вывод: виновато незнание матчасти, если честно. Ничего удивительного по результатам таких запросов не вижу - у нас грубо говоря также.

1. Можно руками прогреть кэш. В 9.4 кажется сделали фишку, чтобы перезапускаться, сохраняя кэши.
// оффтоп: у нас в продакшне за полтора года постгрес перезапускался кажется один раз - а вам зачем это? //
2. Потому что читается с жесткого диска, и индексы большие. См выше.
3. Виноваты только в плане повторных запросов.
4. См. выше, чем больше, тем лучше. На первый запрос - виноват.
5-6. Не совсем правильно. Всё зависит от характера нагрузки и самых медленных запросов, а не от от того, сколько и чего где.

Ааа, парсер.
>> фильтроваться по id

1. Проверьте следующий параметр:
SHOW constraint_exclusion ;
constraint_exclusion
----------------------
partition


2. Проверьте запрос с явным фильтром по партиционируемому полю (WHERE id > ...).

3. Если он ок, то скорее всего для приведенных вами запросов PostgreSQL будет пробегать все партиции, так как ему непонятно, к какой обращаться. Рекомендуют делать явные запросы к нужной партиции, либо фильтроваться по .

Всегда ваш :)