Планы выполнения в pg_stat_statements

Есть много opensource (и еще больше проприетарных) форков pg_stat_statements, которые позволяют смотреть планы выполнения запросов:

pg_stat_plans https://github.com/2ndQuadrant/pg_stat_plans
pg_store_plans https://github.com/ossc-db/pg_store_plans
pg_stat_monitor https://github.com/percona/pg_stat_monitor

Все они мне чем-то не подошли и я написал свое https://github.com/postgredients/pg_stat_query_plans. Расскажу что и как сделал, и что хотелось бы добавить в оригинальный pg_stat_statements, чтобы мое расширение было не нужно

pg укротитель

У разработчиков постоянно возникают проблемы при работе с базами данных. Они вызваны тем, что разработчики считают СУБД чёрным ящиком, который "просто работает" и даже не подозревают, что важно и нужно понимать не только стандарт SQL, но и подробности устройства конкретной СУБД.

Проекты разные, разработчики разные, но вот проблемы как правило одни и те же. Мы хотим продемонстрировать как разработчики пользуются базой данных и рассказать хорошо бы знать об устройстве СУБД, для того, чтобы писать код, который не разваливается как только компания из бодрого стартапа превращается в зрелый бизнес с планомерно растущими продажами и, соответственно, нагрузками.

Практически в любом успешном проекте можно встретить практически одинаковые проблемы. Они появились потому что бизнес хотел побыстрее получить готовый продукт и это в своё время помогло компании встать на ноги. В небольших проектах эти проблемы совершенно незаметны.

pg_migration - система работы с кодом, как не дать программистам все сломать

Мы долгое время катили релизы на базы данных руками. Но когда их количество стало больше 50, выкладывать релизы руками стало больно, даже при наличии скриптов. Стало понятно, что нужен какой-то инструмент. Так как готовые инструменты нам не подошли, мы решили написать свою систему на основе пайплайнов ci/cd в gitlab.

В результате получилась удобная система работы с кодом: - автоматические проверки практически не дают сделать что-то не правильно (plpgsql_check, авто-тесты и т.д.) - исключается возможность расхождения кода в живой БД и в репозитории - включает в себя несколько утилит (написанных на python), которые можно использовать как в пайплайнах, так и непосредственно из консоли - поддерживаются два режима раскатки релизов: по кнопке из gitlab и полностью автоматический (по ключевому слову auto_deploy в сообщении к коммиту)

Диапазонные типы в Postgres

После того, как импортозамещение состоялось, можно немного перевести дух и заняться дальнейшим развитием нашего приложения. При этом оказывается, что Postgres - это не упрощенная версия Oracle, как могло показаться некоторым в процессе миграции, а самобытная СУБД, заметно его превосходящая во многих вопросах.

Поговорим о диапазонных типах - одном из бриллиантов в короне Postgres, про которые, как оказалось, знают далеко не все разработчики.

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

В докладе рассматривается решение нескольких типовых для диапазонных типов задач, что может быть полезно при проектировании новых и развитии существующих приложений.