Зажрался я с Firebird

Сидим c dmzlj обсуждаем проблему "тормозит выборка небольшого данных по хорошему индексу из 40м записей в таблице в PostgreSQL".
Судя по тому вуду, что я почитал про оптимизацию этого дела - мы со своим Firebird, не требующим особого администрирования, зажрались. Потому что там все проблемы сводятся или к перекошенной статистике индексов, или к накопленному мусору в базе. Другое дело что на гигантских базах, типа как народ хочет "280 млн записей" обычный способ лечения backup-restore для FB вряд ли будет приемлем.

Распределенный Postgresql срач

В итоге, в разборки насчет использования dmzlj postgresql под приличной нагрузкой в системе GPS-мониторинга подключили всех до кого смогли дотянутся, вплоть до разработчиков postgresql.

Я потерял нить обсуждения где-то в конце, но судя по результатам, ключевой аспект шизы был в двух вещах: фрагментированность данных и индекса (условно говоря - на каждую интересующую нас запись нужно было читать целую страницу данных, в которой все остальное нас не касалось) и нехватка памяти для кэша, в результате чего все начинало тормозить.

В качестве решения проблемы в итоге предложили какое-то хитрое двухуровневное партиционирование, которое должно устранить проблему фрагментации - сначала партиционировать сильно актуальные данные (текущий день(неделя, месяц)) по hash id объекта, затем переносить данные в партиции по времени кусками с одинаковыми id чтобы избежать фрагментации.

Понял чего не хватает для пополнения рабочего опыта

Поработать где-нибудь полгода-год над 1(одним) сложным проектом, в команде из 5-10-15 человек, не прерываясь ни на что.
Потому что у меня весь опыт - или самостоятельная разработка проектов средней сложности в течение 5 лет, или то же но за два года на пару с ребе belnetmon, или занятие мелкими доработками по 4-5 проектам в день с постоянным переключением между ними, что очень сильно выламывает мозг.