Три независимые попытки сделать для PostgreSQL быстрый точный десятичный тип расширением заглохли. Но не потому, что не получилось ускорить арифметику, — арифметику как раз каждое из них ускоряло. Тогда в чём же дело? Здесь я разбираю технические решения в устройстве numeric, которые приводят к высокой стоимости использования этого типа данных. Изучение провожу в сравнении с устройством типа decimal в DuckDB - будучи OLAP СУБД, он свободен от некоторых ограничений PostgreSQL, и гонясь за производительностью, выбирал другой путь развития.

Большинство материалов о компрессии в PostgreSQL отвечают на вопрос «во сколько раз удалось уменьшить базу». Мы предлагаем посмотреть на проблему с другой стороны: какой ценой достигается эта экономия? В статье разбираем архитектурные компромиссы различных подходов к компрессии страниц, объясняем, почему при разработке CSM в Tantor Postgres отказались от погони за максимальным коэффициентом сжатия, и показываем результаты нагрузочных испытаний на реальных базах 1С.

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

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

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

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

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

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

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

Многие статьи на тему секционирования заканчиваются "и теперь у вас есть партиции". А что дальше - когда нужно обновить данные или отсоединить секцию?

Данные тоже стареют. Им, конечно, не всегда нужен вечный покой — чаще достаточно переехать туда, где они будут занимать меньше места, стоить дешевле в хранении и не мешать тем, кто продолжает работать. В Tantor Postgres эта задача решается не набором разрозненных скриптов, а полноценной системой управления жизненным циклом данных: с регулярным сбором статистики, анализом реальной активности, объяснимыми рекомендациями, аудитом, dry-run и безопасным поэтапным переносом объектов между уровнями хранения. В этой статье мы разберем полный операторский сценарий работы с ILM (information lifecycle management) от появления первых рекомендаций до их безопасного исполнения.

Как мне кажется, старая формула успеха — «сделай хорошо и опубликуй в престижном журнале» — постепенно перестаёт работать. AI не смотрит на статус площадки: он верит тому, что выложено открыто, изложено полно и независимо подтверждено. Почему письмо в публичную рассылку теперь весит больше статьи в закрытом журнале, чем рискуют коммерческие форки PostgreSQL, и при чём здесь борги - об этом я размышляю в этой "отпускной" заметке.

Как ускорить Hash Join в PostgreSQL, отбросив 99% строк ещё до самого соединения? Рассказываем о фильтре Блума в СУБД Tantor Postgres на живых и синтетических примерах.

Я участвую во всевозможных конференциях и митапах с 2004 года. И сейчас, как и в эпоху, когда кнопочная Nokia давала людям первый, совсем ещё примитивный, опыт мобильности, такие мероприятия проходят в одном и том же формате: выступил, ответил на вопросы аудитории, презентацию выложили в сеть. Да, сегодня ещё выкладывают видео на YouTube. Иногда остаётся чат с перепиской, заполненный в основном организационными вопросами. И этим примерно всё и ограничивается.

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

Если конкретно, то я имею в виду слеующее.

В статье рассматриваются особенности использования ограничений целостности с проверкой, которую можно отложить до фиксации транзакции, а также использование системных триггеров для проверки ограничений целостности. Триггеры создаются для любых внешних ключей - и с немедленной и отложенной проверкой, а для уникальных ключей - только для ограничений с отложенной проверкой. Для уникальных откладываемых ключей создаются уникальные индексы, которые допускают неуникальные значения. В таблице могут находиться строки, нарушающие ограничение уникальности, при том, что статус ограничения целостности в системном каталоге "проверено" (validated).

Недавно я изучал вопрос, насколько распространены полиморфные ссылки в реляционных базах — болезненном для производительности паттерне с дискриминированным внешним ключом, который автоматически генерируют ORM-фреймворки (Rails, Django, Hibernate), CRM-платформы (Salesforce) и 1С. Главная страница типичного интернет-магазина или activity-лента CRM-системы строится именно таким запросом: базовая таблица соединяется LEFT JOIN-ами со всеми возможными подтипами через пару столбцов (type, id).

Та статья отвечала на вопрос «насколько распространён подобный паттерн». Ведь если заниматься улучшением, то неплохо понимать, насколько оно полезно, не так ли? Здесь я пытаюсь дать представление о том, каким образом данный шаблон приводит к регрессии производительности и показать направления улучшения оптимизатора PostgreSQL, позволяющие облегчить ситуацию.

Спойлер: пока немного — но кое-что движется на pgsql-hackers. Три патча, обсуждавшихся в 2024–2026 годах, нацелены на три разных источника регрессии. Ниже о каждом.

Аналитика, сканирование интернета стали сегодня сильно проще — даже китайских коллег можно читать совершенно прозрачным образом. Изучение исходников смежных OSS-проектов — это вообще песня: за пять минут, на малознакомом языке программирования и без предварительного знания структуры проекта можно получить ответы на важные вопросы, потырить полезные приёмы и изучить как удачные, так и неудачные архитектурные решения.

Тогда почему мы всё ещё тратим время, ходим на youtube и новостные сайты в поисках интересного контента? Зачем полагаемся на чей-то алгоритм - ведь тот же Claude хранит в том или ином виде историю переписки и таким образом может оценить наши реальные интересы. Может быть стоит взять в свои руки формирование 'информационного пузыря'?

Tantor Postgres 18 - масштабный релиз СУБД, за которым стоят месяцы тестирования, сотни часов нагрузочных прогонов и десятки исправлений, о которых пользователь никогда не узнает просто потому, что они были найдены и устранены до выхода версии. Александр Симонов, руководитель направления развития 1С в "Тантор Лабс", рассказывает, как устроен процесс тестирования изнутри - почему одного эталонного прогона недостаточно, что делать, когда ванильный PostgreSQL 18 ломает собственные оптимизации, и как Tantor Postgres приближается к той планке, которую MS SQL Server держал годами.

ILM (управление жизненным циклом данных) в Tantor Postgres 18 работает в три этапа: администратор задаёт правила, система собирает статистику и выдаёт рекомендации, а вот что делать дальше - решение за администратором. В туториале я последовательно прохожу все эти этапы: установка расширений, настройка tablespace'ов, работа с обычными и секционированными таблицами и проверка рекомендаций через Flamegraph. В общем, разбираю новый функционал с практической стороны.

Enterprise-разработка рано или поздно сталкивается с классической задачей: нужно выдать доступ к БД аналитикам, тестировщикам или саппорту в проде, но при этом необходимо скрыть персональные данные или коммерческую тайну. Статическое маскирование отлично подходит для случаев, когда таблица копируется полностью, но что если “замаскировать” нужно просто результат какого-либо запроса? Здесь пригодится маскирование динамическое, и в этой статье мы рассказываем об инструменте transp_anon, который входит в новый релиз СУБД Tantor Postgres 18.

Планы выполнения запроса формируются на основе текста самого запроса, статистик и параметров конфигурации. Для сбора статистики нужны данные в таблицах. В PostgreSQL 18 версии появились функции pg_restore_relation_stats и pg_restore_attribute_stats, которые могут записать статистики в системный каталог. Вместе с возможностью выгрузки статистики параметром утилиты pg_dump --statistics-only, статистику стало возможым переносить между базами данных.

Функционал переноса статистики был создан для обновления кластера баз данных на новые версии. До 18 версии статистика не выгружалась, собиралась после обновления. Сбор статистики по большому числу таблиц довольно долгий. Начиная с 18 версии, утилита pg_upgrade, по умолчанию, сохраняет статистику.

Этот же функционал можно использовать для переноса статистики с промышленных на тестовые базы данных. В статье рассматривается как это сделать.

В 18 версию СУБД Tantor Postgres включено расширение pg_ilm, реализующее функционал управления жизненным циклом данных (Information Lifeсycle Management. Расширение отслеживает «температуру» данных (горячие → остывающие → холодные) и частично автоматизирует их перенос в колоночное хранилище или на более дешёвый носитель согласно заданным правилам. В статье —очерк о том, как все начиналось, к чему мы пришли в процессе разработки, наглядная демонстрация возможностей этого расширения с живыми примерами и пара слов о дальнейших планах.