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

Время от времени приходится слышать мнение, что Postgres никуда не годится для решения задач аналитики. При при этом, в качестве аргументации приводятся в пример результаты тестирования на TPC‑H или ClickBench. Что ж, когда стоит простая задача перебрать 100 млн строк на диске и посчитать набор агрегатов над ними — формат хранения и распараллеливания действительно сильно ограничивают нас в возможностях оптимизации СУБД. Однако когда запросы высоко селективны, им по факту требуется не так много строк таблицы и фокус внимания смещается на порядок JOINов, кэширование промежуточных результатов и минимизацию операций сортировки. В этом случае Postgres, имеющий весьма широкий выбор различных стратегий выполнения запроса, может получить преимущество...

Побывав на PGConf.DE’2025 и обсуждая там практику применения Postgres на больших базах данных, я к своему удивлению регулярно слышал мнение, что проблемой является время планирования запроса. Как разработчику, мне было странно узнать, что этот фактор может, например, тормозить принятие решения о переходе на партиционирование, что казалось бы естественный шаг, когда количество записей в таблице переваливает за сотню миллионов. Что ж, давайте разбираться.

Сегодня я хочу затронуть тему дополнительных ухищрений, которые могут позволить ускорить выполнение запроса. В данном случае речь пойдёт о перестановке условий в выражениях фильтрации, JOIN'ов, HAVING-клаузах и прочем. Идея заключается в том, что получив негативный результат в одном условии из цепочки выражений, объединенных оператором AND, равно как позитивный результат в одном из условий, объединённых оператором OR, можно не вычислять все последующие и сэкономить вычислительный ресурс. Что это даёт и как конкретно реализовать - об этом ниже.

Здесь я описываю результаты разработки одного расширения Postgres, которое сделал просто ради любопытства. Суть его состоит в автоматическом управлении расширенной статистикой по колонкам таблицы. Идея родилась в момент, когда заканчивая работу над очередным "умным" query-driven продуктом улучшения качества планирования Postgres я осознал, что архитектура этой СУБД пока ещё не готова к полностью автономной работе - автоматическому детектированию плохих планов и подстройки оптимизатора. Так может быть зайти с другой стороны, и попробовать сделать автономный data-driven помогатор?

Речь здесь пойдёт о стабильности стандартной статистики Postgres и об идее очередного расширения - на этот раз альтернативы команде ANALYZE. Всё началось с того, что заканчивая работу над предыдущей статьёй я вдруг заметил, что результат выполнения одного и того же запроса теста Join Order Benchmark (JOB) в серии последовательных прогонов может отличаться в разы и даже на порядки - причем как по значению параметра execution-time, так и по pages-read. Это выглядело очень странно, поскольку и тест и ноутбук и все настройки оставались теми же - даже погода за окном. И я решил расследовать, что происходит …

Как сравнить? - измерить execution-time конечно! - скажет опытный читатель. И будет совершенно прав: с практической точки зрения эффективнее та СУБД, которая выдаёт больший TPS. Однако иногда нам требуется спроектировать систему, которой ещё нет или сделать прогноз поведения на нагрузках, которые ещё не пришли. В таком случае нам нужна некоторая характеристика, позволяющая выполнить качественный анализ плана или выполнить сравнение пары планов. Обсуждению одной такой характеристики - количество прочитанных страниц данных - и посвящён данный пост.

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

Здесь я привожу четыре случая, когда SQL Server позволяет строить планы запросов значительно более оптимальные, нежели это доступно PostgreSQL используя как более широкое пространство возможных планов, так и более совершенные методы оценок эффективности планов. Эти примеры: использование тредов, расширенная статистика, кэширование промежуточных результатов запроса и внутренняя параметризация. Примеры независимы и все кроме первого содержат скрипт воспроизведения - можно сразу листать на ту часть, которая выглядит интереснее.

Полагаю, знание о таких кейсах может быть полезным. Как минимум уменьшит количество стресса при миграции на PostgreSQL и возможно заинтересует кого-то настолько, чтобы начать свой проект в open-source сообществе разработчиков СУБД.

В то время, как пользователи видят позитивные стороны технологий, мы, разработчики, обычно сталкиваемся с ограничениями/недоработками/багами и видим наш продукт с совсем другой стороны. Вот и в этот раз: после публикации результатов сравнительного тестирования где я прогонял запросы теста Join-Order-Benchmark на базе с партициями и без, меня не отпускало ощущение, что всё-таки что-то я не досмотрел и при наличии партиций постгрес должен строить план хуже, чем без них. И это должен быть не просто баг, а технологическое ограничение. И вот, методом разглядывания потолка удалось-таки найти тонкое место - запросы с лимитами.

Пользователи PostgreSQL нередко оперируют аналитическими запросами, при выполнении которых данные сортируются и группируются по разным правилам. За счёт оптимизации вычисления агрегатов и сортировок можно значительно сократить время и стоимость выполнения запросов. Об одной из таких оптимизаций — выборе порядка колонок в выражении GROUP BY — расскажем в этой статье.

Postgres уже умеет перестраивать список группируемых выражений в соответствии с порядком колонок из условия ORDER BY, чтобы исключить дополнительную сортировку и сэкономить вычислительные ресурсы. Мы пошли дальше, реализовали свою идею в дистрибутивах Postgres Pro Standard и Enterprise и вынесли патчи на обсуждение сообщества Postgres (первое и второе) в надежде, что они войдут в ближайшую версию ванильного PostgreSQL.

В моей работе, когда приходится исследовать и нагружать СУБД нетипичной нагрузкой и синтетическими тестами, часто встречаются случаи загадочного поведения системы: ускорение/замедление времени выполнения запроса на пару порядков, отказ использовать тот или иной индекс и тд. Объяснение странного поведения оказывается в итоге почти всегда тривиальным и хорошо известным опытным DBA. Однако встретив его в реальной эксплуатации первый раз невольно теряешься и на разбор кейса уходит много времени. Вместе с тем, это достаточно интересное упражнение - навроде того, как прорешать задачник по аэродинамике после 10 лет проектирования планеров самолётов. Поэтому предлагаю здесь попробовать формат обсуждения/изучения PostgreSQL в виде задач. Вдруг зайдёт?

Недавно, на хабре вышла статья про один нюанс в оптимизаторе PostgreSQL [1]. Будучи предельно технической и скучной по-определению, она триггернула интересную дискуссию в комментах и дала мне, как разработчику систем баз данных, возможность взглянуть на систему с точки зрения разработчика приложений. Это оказалось крайне продуктивным и даже привело к патчу и треду в сообществе. Возможно, нам нужно больше таких небольших и узко-специализированных постов? Данная статья - попытка развить это направление.

[1] Странное поведение планировщика запросов PostgreSQL