PGConf.Russia 2024

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

Фаззинг-исследование, это когда мы подаем в программу (или ее часть) случайные входные данные (на самом деле случайность весьма условна) и смотрим что из этого получится. И так много раз на многих процессорах.

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

Исследование функций парсинга типов данных (input-функции): для разогрева;
Исследование функций реализующих операции между типами (op-функции): тут лучше учитывать структуру;
Фаззинг сетевой подсистемы: давайте притворимся, что мы POSIX-вызовы, так дешевле;
Восстановление дискового контекста: нужен день сурка.

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

Есть много 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, чтобы мое расширение было не нужно