Какие есть варианты оптимизации/увеличении производительности Postgre?

Question

[ZzZero]

Приложение имеет свыше двухсот таблиц, из которых 15 таблиц используются постоянно, основные таблицы приложения. Есть таблицы в ширину по 150 колонок.
Все таблицы соответствуют норльманым формам, индексами покрыты (в т.ч. и составными) большая часть запросов SELECT.
Столкнулся с двукратным падением производительности БД.
Есть таблицы, которые ежедневно пополняются примерно на 10тыс строк (в ширину по 150 колонок).
В приложении нет вариантов дешевой и "средней" оптимизации, количество запросов и их сложность свиденена к минимуму, много что кэшируется.
Как вообще администрировать БД? Есть у кого какие идеи, не увеличивая вычеслительные мощности?

Answer 1

[lega]

Я бы залогировал время выполнения всех запросов, составил топ самых медленных и начал с верха разбирать каждый запрос.

Все таблицы соответствуют норльманым формам, индексами покрыты (в т.ч. и составными) большая часть запросов SELECT.

Большое кол-во join-ов снижают производительность, вложенные селекты могут убивать производительность т.к. на них нет индексов. Так же зачастую разработчики ставят неправильные индексы что дает не максимальную производительность - не достаточно просто "установить" индексы на нужные поля.
Но это все разработчику, админу наверно остается следить что-б памяти хватало, да в cpu/io не упиралось (ну и может статьи по тюнингу почитать)

Comments

[ZzZero]

Да, спасибо.
Конечно оптимизации, совершенству - нет предела, но в целом, явно "плохих" запросов нет.
Хотелось бы попробовать решить вопросы с базой данных - на уровне самой БД.
Может у вас есть под рукой хорошие статьи про тюнинг, антисоветы к постгре?

[lega]

под рукой нет, но вроде на хабре что-то видел