Другие доклады
-
Руслан Рангулов ПАО «Софтлайн» Инженер отдела Премьер Сервисов по бизнес-приложениям
Проверка на прочность. Утилиты для анализа и оптимизации PostgreSQL
Внедрение и эксплуатация PostgreSQL могут быть сложными задачами, особенно когда речь идет о поддержании здоровья и производительности базы данных. Однако, использование специализированных утилит для проверки состояния системы позволяет облегчить их решение. В ходе выступления мы поговорим об инструментах, которые помогают администраторам и разработчикам эффективно конфигурировать и искать проблемы PostgreSQL, рассмотрим утилиты проверки баз данных, такие как postgresqltuner, postgres-checkup, pgdsat, PG Collector, а также поделимся собственным опытом и подходами к поиску проблем, возникающих при внедрении и эксплуатации PostgreSQL.
-
Михаил Сироткин Postgres Professional стажёр
pg_uprobe: Профилируем Си-шные функции PostgreSQL без боли и печали
Профилировать программы с помощью gdb/perf/ebpf/whatever бывает накладно по ряду причин. ebpf/perf выполняются в пространстве ядра, PostgreSQL работает в пользовательском пространстве, а переключение между пространстами может сильно ухудшить производительность. Также профилирование требует специальных привелегий, которых часто не хватает, и может сильно отличаться на разных операционных системах. Расширение pg_uprobe для PostgreSQL решает выше перечисленные проблемы: -не содержит внешних зависимостей аля ebpf/perf/whatever -легко установить (как и любое другое расширение) -профилирует отдельные бекенды и не только это... Приходить на наш доклад чтобы узнать как этим можно пользоваться, как оно реализовано внутри.
-
Денис Пантилеенко ООО Администратор баз данных
-
Алена Рыбакина Postgres Professional разработчик
Адаптивный исполнитель запросов
К сожалению, уже давно известны случаи, когда оптимизатор строит неоптимальный план запрос, и часто данные случаи связаны с неверной оценкой кардинальности - из-за ожидания малого количества данных, оптимизатор предпочитает выбрать NestedLoop вместо других соединений, из-за чего время выполнения запроса может растянуться по времени. Наша команда разработала расширение SwitchJoin, которое имеет возможность, помимо основного выбранного оптимизатором пути NestedLoop, сформировать запасной, и, в случае, если количество кортежей было предсказано слишком малое, может переключаться на него.