За пределами EXPLAIN: как увидеть выполнение запроса вживую в Greenplum/Cloudberry

Базы данных и системы хранения

Асинхронное программирование, реактивное программирование

Профилирование

Распределенные системы

Разработка библиотек, включая open source библиотеки

Архитектура данных, потоки данных, версионирование

Логирование и мониторинг

Администрирование баз данных

Логи, метрики, ошибки

Программный комитет ещё не принял решения по этому докладу

Целевая аудитория

DBA, SRE и бэкенд-разработчики, кто работает с PostgreSQL / Greenplum / Cloudberry и дебажит медленные запросы. Кому интересны observability и внутреннее устройство СУБД.

Тезисы

SQL декларативен: ты пишешь что получить, а как выполнять - выбирает СУБД. В PostgreSQL этот выбор виден через EXPLAIN: вот план, вот узлы, вот оценки. Но план статичен. Пока тяжёлый запрос крутится минутами, главный вопрос - «на каком шаге мы прямо сейчас и почему так долго?» - остаётся без ответа: EXPLAIN ANALYZE отдаёт статистику только постфактум, а оценки планировщика часто расходятся с реальностью.

Для обычного PostgreSQL подсмотреть выполнение вживую способы есть. Но в распределённой MPP-СУБД запрос идёт параллельно на сотнях узлов кластера, разбитый на части, - и готовые решения тут не работают, пришлось написать свое. Мое расширение позволяет строить дерево плана выполнения на основе runtime статистик бегущего запроса.

Расскажу, какие задачи удалось решить и обо что споткнулся: как собрать статистику с сотен процессов, не положив координатор, и что делать с тем, что часть привычной по EXPLAIN ANALYZE статистики в runtime попросту недоступна. Обсудим оверхед и границы применимости.

Алексей Рожок

Яндекс

Занимается open-source разработкой Apache Cloudberry. Увлекается бегом и музыкой.