PostgreSQL *

Агрегаты в PostgreSQL не очень-то эффективны. Это особенно заметно в сравнении с SQL Server в сценарии, где частичная агрегация не помогает: когда агрегация только подготавливает данные для запроса, обрабатывая большой поток строк и на выходе получая ненамного меньший набор групп и посчитанных по ним агрегатов. Хуже всего приходится типам переменной длины. И здесь характерный пример — SUM(numeric). Встроенные агрегаты обязаны обрабатывать значения в самом общем виде, тогда как на практике данные часто ограничены: например, в БД 1С все numeric имеют фиксированный масштаб.

Отсюда возникает идея оптимизировать агрегаты, подстроив их под конкретные условия эксплуатации. Раньше это было возможно только в форке PostgreSQL. Однако недавно David Rowley добавил в ядро любопытный инструмент расширения SupportRequestSimplifyAggref (коммит 42473b3b31, PostgreSQL 19): теперь можно предоставить планнеру кастомную логику трансформации агрегата через механизм функций поддержки планнера (prosupport). Сам механизм существует ещё с PostgreSQL 12, но до агрегатов добрался только сейчас. В ядре новый запрос применяется скромно: заменяет COUNT(1) и COUNT(col) по NOT NULL-колонке на COUNT(*). А вот расширению он позволяет сделать с агрегатом во время планирования практически что угодно. Это открывает пространство для интересных технических решений.

Здесь я предлагаю посмотреть, как схема с преобразованием агрегата работает на живом и полезном примере — простом расширении с достаточно примитивной трансформацией.

Про асинхронный ввод-вывод в PostgreSQL за последний год написали многие:

Механизм появился в 18-й версии, в 19-й его докрутили и в релиз-нотах он числится среди главных улучшений производительности.

По ходу чтения релиз-нотов я сам столкнулся с множеством вопросов, поэтому поставил стенд, погонял нагрузку, померил, посмотрел на результаты. Далее, в статье маршрут моего похода выходного дня: где апгрейд на 19 ускоряет и на сколько, где не меняет ничего, где настройкой можно выжать ещё вдвое и где два параметра способны выключить всю фичу целиком.

Так получилось, что пару десятилетий занимался в тои числе и базами данных. Ставил. Тюнил. Выносил логику В базу. Вынос иллогику ИЗ базы. Поднимал когда падали... Когда перешёл в большой SRE‑спорт, почти октаду лет поддерживал экзабайтные аналитические query engine. В общем, развлекался, как мог.

Главное открытие заключалось в том, что почти всё, что считается невозможным, случается. Люди креативны. Ты им дашь регексп — и они начнут майнить биткойны. Ты им дашь data lake — и они начнут хранить данные в именах таблиц. Ты им дашь GEO... Сам виноват.

Но самое интересное в том, что есть пласт проблем, который лежит совсем не в области современных сверхсложных методов параллелизации обработки, а в наследии 80ых годов прошлого века. То, что никого раньше не волновало, внезапно стало вызывать сбои. Причём в самом лучшем их проявлении — всё работает, клиент доволен, система растёт, цветёт и пахнет. А в один внезапный день запросы не работают, сервер падает, и что делать непонятно, так как никто ничего не менял.

И это ещё хороший сценарий, так как никто ничего плохого и не хотел: можно поймать запрос, заблокировать, и спокойно разбираться.

Часть 1. Как я делаю backend для браузерной игры три в ряд: server-driven персонажи и способности, общий контракт клиента и сервера, версионирование контента, транзакции, идемпотентность и админка.

При создании отказоустойчивых систем стремятся гарантировать отсутствие потерь транзакций при восстановлении из бэкапов или при переключении на реплику. В статье рассматривается, как в коде приложения можно выяснить, была ли потеряна транзакция при переключении на реплику, а также если команда на фиксацию была отправлена, но подтверждение о том, что она зафиксирована получено не было. Вы познакомитесь с техникой (шаблоном написания запросов) Transaction Guard.

Построение HA-кластера в PostgreSQL традиционно требует внешнего стека: Patroni, распределенного хранилища конфигураций и набора вспомогательных утилит. В СУБД Postgres Pro Standard и Enterprise отказоустойчивость реализована на уровне ядра: механизм BiHA берет на себя консенсус Raft, защиту от split-brain и перестроение топологии.

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

Документация PostgreSQL по numeric содержит два плохо согласующихся утверждения:

«especially recommended for storing monetary amounts and other quantities where exactness is required» — и сразу же: «calculations on numeric values are very slow compared to the integer types, or to the floating-point types». То есть рекомендуют для хранения денежных величин и тут же признают, что это весьма дорого.

Для меня, как разработчика СУБД это сигнал к действию. Если операции с типом заметно медленнее bigint, возникает соблазн: а нельзя ли хранить денежные величины целым числом копеек и округлять по стандартному правилу? Это бы прилично сэкономило вычислительные ресурсы наших серверов баз данных, разве нет? А что, если вообще использовать double precision?

Недавно я написал свою систему распределённой обработки задач. Сначала это был учебный проект. Мне хотелось лучше разобраться в очередях задач, координации воркеров, блокировках строк в PostgreSQL, retry‑механизмах и планировании фоновых задач.

Когда основная функциональность была готова, я понял, что не знаю, как система ведёт себя под нагрузкой.

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

Увеличение количества воркеров с 16 до 32 практически не дало прироста производительности, а при 64 воркерах ситуация стала ещё интереснее: задачи, которые должны были выполняться около 0.5 секунды, начали занимать больше секунды.

Первой моей мыслью было, что я упёрся в PostgreSQL.
Оказалось, что нет.

Привет, Хабр!

Меня зовут Жуйков Андрей, занимаюсь развитием и продвижением СУБД Digital Q.DataBase.

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

В этой статье я покажу, как установить Digital Q.DataBase 18.2 на РЕД ОС 8.0.3, познакомлю с новой архитектурой СУБД и продемонстрирую подключение к каждому из поддерживаемых диалектов.

Если вы пишете SQL‑запросы, то наверняка сталкивались с ситуацией, когда данные исчезают, отчеты не сходятся, а бизнес теряет деньги. И виновник этого — маленькое, но очень коварное слово NULL. В 1974 году Эдгар Кодд, создатель реляционной модели данных, ввел это понятие, чтобы обозначить отсутствие информации. Он хотел, как лучше, но спустя пятьдесят лет NULL продолжает «терроризировать» разработчиков по всему миру. Важно усвоить раз и навсегда: NULL — это не значение. Это состояние неизвестности.

Поэтому:

· NULL ≠ 0 (ноль — это число);
· NULL ≠ '' (пустая строка — это строка);
· NULL ≠ ' ' (пробел — это символ).

Но всегда есть нюансы и исключения. Например, в Oracle INSERT INTO table (col) VALUES ('') запишет NULL. Это поведение отличается от других СУБД и часто становится сюрпризом при миграции.

Когда речь заходит об оптимизации запросов в PostgreSQL, разработчики, как правило, сосредотачиваются на времени выполнения: индексы, планы запросов, настройки памяти и так далее. Время планирования остаётся в тени. А зря! Планировщик работает перед каждым выполнением запроса. Для OLTP‑нагрузки с короткими транзакциями накладные расходы на планирование могут составлять значительную долю от общего времени ответа. Для запросов с большими IN‑списками и высоким statistics_target планирование может занимать сотни миллисекунд, тогда как само выполнение укладывается в миллисекунды. Поэтому ускорение планировщика не менее важно, чем ускорение выполнения.

В статье рассматривается исполнительная часть утилиты ggrebalance: механизм физического перемещения primary- и mirror-сегментов между хостами кластера Greengage DB (open-source форк Greenplum), устройство конечного автомата ребаланса, отслеживание статусов операций, обработка сбоев и реентерабельность, откат перемещений, а также практические рекомендации по эксплуатации и итоговое сравнение с альтернативными инструментами.

CPU и диск свободны, а сервис уже задыхается: транзакции ждут блокировок, соединения заканчиваются, база перестаёт отвечать.

Разберём, как найти корневой процесс в PostgreSQL, отличить длинную транзакцию от конкуренции за строки и остановить каскадный сбой.

База данных — бизнес-критический компонент любой ИТ-инфраструктуры, поэтому вопрос обеспечения ее доступности и отказоустойчивости обычно находится в центре внимания. Однако, фокусируясь на отказоустойчивости, компании нередко недооценивают риск переполнения диска. При этом подобные ситуации могут оставаться незамеченными до полной остановки записи БД, например при заполнении отдельного раздела, где хранятся данные или WAL.

Привет, Хабр. Меня зовут Александр Шмелёв. Я Team Lead команды разработки Databases, VK Tech. В этой статье я расскажу о рисках и причинах переполнения дисков, а также рассмотрю несколько способов предотвращения подобных проблем.

В данной статье я хочу рассказать о проверке одной гипотезы - возможности использования shared memory для ускорения параллельной агрегации методом хэширования. Статья Xu&Marcus, PVLDB, 2025 утверждает, что общая хэш-таблица — незаслуженно списанный со счетов способ параллельной агрегации, если использовать т.н. тикетинг и разделить операции поиска группы и обновления агрегата.

Звучит завлекательно. Собираем в кучу свои знания Internals, подписку на Claude и, поскольку в период летних Heat Wave выходные всё-равно проходят дома под кондиционером - разрабатываем идею так глубоко, насколько это получится.

SELECT * FROM document, client(document)

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

Бывают ошибки, которые не видит ни ревью, ни тесты: код отрабатывает правильно, прогон зелёный, а запросов к базе он делает в сто раз больше прежнего. Я убрал из фонового планировщика классический N+1 — самым что ни на есть учебным способом — и чуть не выкатил в прод версию, где нагрузка росла как квадрат числа пользователей. Разбираемся с замерами в руках: при чём тут expire_on_commit, почему предзагрузка пачкой сама по себе ни в чём не виновата и как одна строка превращает цикл в N².

При переносе большой системы разработанной под одну СУБД на другую неизбежно возникают различные нюансы, то? что эффективно работало в одной СУБД, уже не так эффективно (или совсем неэффективно) работает в другой.

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

Сегодня я хочу рассмотреть один частный случай, связанный с обработкой аналитических (оконных) функций оптимизаторами Postgres и Oracle.

Что получится, если собрать PostgreSQL, Airflow, JupyterLab, MinIO, Superset, шесть MCP-сервисов и локальную модель Ollama в одном Docker Compose-стенде?

Показываю полный путь синтетических промышленных данных: от витрин и проверок качества до Parquet-артефактов, MCP-инструментов и LLM-пояснений. Внутри — архитектура, воспроизводимый запуск, результаты проверок и открытый репозиторий.

pgrust это СУБД или злая шутка?

Майкл Мэйлис (Michael Malis), житель Сан Франциско, основатель freshpaint‑io, работал в компании Heap — человек в мире Postgres не слишком известный, хотя давний пользователь. Он, скорее, из мира фанатов Rust и Common LISP. Он был бы возмутителем спокойствия Postgres‑сообщества — да чего там: ИТ‑сообщества — если б там сейчас было какое‑то спокойствие.

У него есть свой сайт — malisper.me. Там многое рассказано, хотя наиболее шустро новость разошлась с форумов — с рэддит: pgrust: Postgres rewritten from scratch in Rust, currently passing 34% of the Postgres test suite, или с ycombinator: Postgres rewritten in Rust, now passing 100% of the Postgres regression tests. В рунете новость появилась на OpenNET.ru: pgrust — клон PostgreSQL на Rust, проходящий все регрессионные тесты.