PGConf.Russia 2025

Мастер-класс с демонстрацией работы pg_probackup3

При нагрузочном тестировании PostgreSQL бенчмарки замеряют время исполнения запроса (latency). Для более объективного результата запрос выполняется большое количество раз — из этого получается некоторый набор latency. Для оценки производительности PostgreSQL на данном запросе можно использовать стандартные методы, такие как медиана или среднее, но мы предлагаем использовать более комплексный подход. Как показала практика, такие выборки часто бывают мультимодальными и состоят из различных распределений с некоторыми параметрами. 

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

Доклад содержит рассмотрение двух случаев длительного выполнения create database в PostgreSQL 11, которые в кластерной конфигурации Corosync/Pacemaker приводили к переключению нод из-за таймаута мониторинга от кластерного ПО. Первый случай связан с большим размером shared buffers, а второй — с использованием опции WITH OWNER при создании БД и большим размером системной таблицы pg_shdepend (особенность использования ПО jBPM).

Столько слов было сказано о PostgreSQL как о результате работы его программного кода. Но Postgres — это не только код. Это люди, которые его создают, развивают и... Оставляют в нём частичку себя через комментарии.

Какие истории нам могут рассказать комментарии к коду PostgreSQL? Узнаем, какое слово самое популярное, какие комментарии остались в коде с самого первого публичного коммита,  как меняется стиль общения с развитием продукта и как за строчками кода и комментариев увидеть человека.