Я тут ковырял MSSQL в одном проекте, а там использовалось page data compression для разного второстепенного барахла, что здорово сжимало данные и уменьшало IO. И надо сказать page data compression отлично подходит если данные меняются редко, а жмутся хорошо. И вспомнил, что в Postgres есть аналог, ну как аналог... штука, которую тоже можно использовать для сжатия данных - TOAST. И нашёл статью, где неплохо описывается в т.ч. структура (как оно лежит внутри) - и да, это полезно для понимания процессов и применения - где/когда можно, а где не стоит. #postgres

Ну это уже перебор я щитаю.
Зачем, зачем так делать? #postgres

Ещё один закат солнца вручную - message queue поверх Postgres - pgmq.

Зачем? Не знаю.
Почему? Потому что могут!

Пытаюсь придумать кейс для использования, но что-то пока не выходит. Вроде и версия 1.45, хоть щас в прод! :))) #postgres

Интересная книга "The Internals of PostgreSQL" с картинками! По краткому прочтению - must have для разработчиков. #postgres

Пара статей (раз, два) про интересные индексы в Postgres типа BRIN (Block Range Index) - когда в индексе сохраняется мин/макс значения для блока страниц. Такой подход позволяет получить очень маленький объем индекса - единицы мегабайт даже для сотен миллионов записей (и можно поиграть с размером блока, основываясь на конкретных данных, чтобы понять какой вариант наиболее выгоден).

Но не забываем, что каждый инструмент имеет свои возможности и ограничения. #postgres