PGConf.Russia 2022

Чем больше таблиц участвует в запросе, тем сложнее планировщику выбрать подходящий план выполнения (увеличивается время и используемая память). Как бы подсказать планировщику, что лучше эту пару таблиц соединить первой, а остальные - потом? Как поступить, если видно, что часть запроса можно улучшить, но оптимизатор этого не делает? В докладе я расскажу про управление порядком соединений - вы узнаете, как можно повлиять на формирование плана запроса стандартными способами "ванильного" PostgreSQL.

Облачный провайдер оперирует большим количеством железных ресурсов и сетевых сущностей. Но одно дело, когда компания запускает десятки инстансов БД в изолированном контуре для внутренних задач. Совсем другое — когда облачный провайдер предоставляет услуги b2b-пользователям и создает сервис для 500+ крупных компаний.

Виталий расскажет, как сейчас работает Managed PostgresPRO у облачного провайдера VK Cloud Solutions, покажет архитектуру решения и расскажет о сложностях, с которыми столкнулись при создании продукта.

Более семи лет назад вышел PostgreSQL 9.4, в котором впервые появились функции логического декодирования и слоты репликации. И, спустя несколько лет, на базе этих функций в PostgreSQL 10 наконец то появилась поддержка логической репликации встроенная в ядро. Казалось бы, наступило солнечное будущее к которому мы так долго шли, если бы не пара неприятных моментов: логическая репликация не работает на репликах, плюс в PostgreSQL нет механизмов создания логических слотов на реплике. Это означает что при переключении мастера на новый узел слоты репликации теряются и на практике делает невозможным использование логической репликации и CDC для серьезных промышленных решений.

Postgres-hackers уже много лет пытаются найти решение данной задачи, но к сожалению большинство попыток и горяих дискуссий в рассылке не привели ни к чему конкретному. Но, оказывается в PostgreSQL 11 была добавлена одна маленькая функция, которая позволила решить проблему потери слотов логической репликации с помощью внешних инструментов.

В докладе я расскажу как Patroni решает данную проблему используя исключительно на возможности PostgreSQL. Мы поговорим о плюсах и минусах данного решения, и попытаемся понять безопасно ли это немного погрузившись во внутренности Postgres.

Доклад посвящён применению PostgreSQL, LUI и LUI4ORA2PG для построения системы аналитической отчётности. В докладе излагаются следующие темы: * миграция из среды Oracle; * применение функций JSON; * как нам помогли временные таблицы; * собственные средства нагрузочного тестирования и выявление “узких” мест; * как делать красивые карты формата GeoJSON для отображения на них диаграмм; * установка и тестирование системы на ЭВМ “Эльбрус”; * чего нам не хватало или мешало в PostgreSQL.

С историей развития инструмента разработки web-приложений Live Universal Interface (LUI) и инструмента миграции LUI4ORA2PG, можно ознакомится по предыдущим выступлениям на конференциях PgConf:

https://pgconf.ru/2019/118109 ;

https://pgconf.ru/201911/264095 ;

https://pgconf.ru/2020/262456 ;

https://pgconf.ru/2021/288310 .