Бытует мнение, что чем детальнее статистика по данным, тем лучше планировщик PostgreSQL выбирает планы выполнения запросов. Однако у этой точности есть скрытая цена. Из доклада вы узнаете, как рост объема и детализации статистики приводит к резкому росту вычислений внутри планировщика, какие алгоритмы внутри него перестали масштабироваться и как в будущей версии PostgreSQL данный класс проблем будет устранен.

Оптимизатор запросов PostgreSQL весьма продвинут, но и он допускает ошибки. Стандартные инструменты вроде pg_stat_statements показывают лишь фактические метрики выполнения, но отнюдь не реальную оптимальность планов. Запрос, выполняющийся за 100 мс, может выглядеть быстрым, однако если планировщик ожидал 10 000 строк, а получил 100, — возможно, при правильной настройке этот запрос выполнялся бы вдесятеро быстрее, давая на масштабе значительный прирост производительности. В докладе я расскажу о pg_track_optimizer — открытом расширении, разработанном для выявления ошибок планировщика с большим разнообразием запросов. В его основе — метрики, позволяющие сравнивать ожидания планировщика и реальность, и выявлять узкие места до того, как они повлияют на систему.

При масштабировании систем на базе 1С и PostgreSQL возникает потребность в переносе аналитических запросов на реплики. Однако стандартное ограничение PostgreSQL на работу с временными таблицами в режиме read-only блокирует этот путь. Мы расскажем о природе этого ограничения, представим техническое решение через модификацию исходного кода СУБД и продемонстрируем его эффективность на результатах нагрузочных тестов с несколькими тысячами одновременных пользователей в реальной инфраструктуре 1С.

Почему это важно? Активное развитие СУБД на основе PostgreSQL подталкивает к регулярному обновлению мажорной версии СУБД в промышленных рабочих средах. Базовый сценарий обновления через резервное копирование и восстановление может быть долгим. Альтернативный путь с использованием штатного инструмента pg_upgrade часто выбирают ради скорости и нередко не учитывают особенностей процесса. В докладе я разберу типовые ошибки и необходимые корректировки планов обновления.

Я 19 лет занимаюсь администрированием и SQL-оптимизацией в СУБД, из них 12 - в PostgreSQL. Не секрет, чем больше таблиц в БД, тем сложнее с ней работать. Это касается и производительности автовакуума (особенно при конкурентных изменениях в разных таблицах), и скорости планирования запросов, и разрастания системного каталога. А когда таких БД не одна, а несколько десятков, возникают специфические требования к их обслуживанию и эксплуатации. Из моего доклада вы узнаете о подходах, которые помогают в разы увеличить производительность, высвободить аппаратные ресурсы и значительно упростить поддержку.

Я расскажу о том, как «переезд» Patroni-кластера PostgreSQL с CentOS 7 на Oracle Linux 8 обернулся, помимо смены ОС, еще и пересмотром архитектуры кластера, вынесением клиентов на балансировщик, обновлением практически всех ключевых компонентов — Patroni, etcd и других. Необходимо было учесть множество факторов, таких как разница в ядре и библиотеках ОС. Однако предвидено было далеко не всё, что должно было быть. Надеюсь, мой опыт поможет слушателям избежать ненужных ошибок в такого рода процессах.

В PostgreSQL исторически поддерживается несколько десятков языков программирования. Если этого недостаточно, можно воспользоваться готовым расширением из огромной экосистемы либо написать своё. Прогресс не стоит на месте, и теперь для выполнения стороннего кода в PostgreSQL можно использовать WASM. На примере Luxms BI я расскажу, как мы автоматически генерируем Swagger-документацию прямо внутри PostgreSQL с помощью open-source технологий и WASM.

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