Недавно я изучал вопрос, насколько распространены полиморфные ссылки в реляционных базах — болезненном для производительности паттерне с дискриминированным внешним ключом, который автоматически генерируют 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. Расширение отслеживает «температуру» данных (горячие → остывающие → холодные) и частично автоматизирует их перенос в колоночное хранилище или на более дешёвый носитель согласно заданным правилам. В статье —очерк о том, как все начиналось, к чему мы пришли в процессе разработки, наглядная демонстрация возможностей этого расширения с живыми примерами и пара слов о дальнейших планах.

В PostgreSQL процесс получения журналов walreceiver запускается на реплике только после того, как процесс startup применит все накопившиеся WAL. Это не создаёт особых проблем, если процесс startup успевает накатывать полученные журналы. Проблема проявляется, если используется реплика с отложенным применением журнальных записей, например, на сутки. Реплика не будет получать журналы сутки, слот репликации будет их удерживать на мастере.

Если процесс walreceiver остановится, то он не запустится до тех пор, пока не пройдёт время задержки, установленное параметром recovery_min_apply_delay. Команд ручного запуска процесса walreceiver нет. Получится, что сутки мастер копит журналы, только потом запускается walreceiver и начинает вытягивать журнальные файлы. Такое поведение нелогично, но его задокументировали: "When the standby is started and primary_conninfo is set correctly, the standby will connect to the primary after replaying all WAL files available in the archive. If the connection is established successfully, you will see a walreceiver in the standby, and a corresponding walsender process in the primary."

Всё время, до запуска walreceiver, слот репликации на мастере удерживает файлы журналов. На мастере скопится много журналов и, если не хватит места, то экземпляр мастера подвиснет по нехватке места в директории pg_wal (или слот инвалидируется по параметру max_slot_wal_keep_size и реплику придётся пересоздать).

HTAP — одна из главных тем в мире СУБД. Вокруг PostgreSQL массово появляются конструкции с внешними аналитическими движками со своими моделями хранения данных и ограничениями совместимости, однако бизнесу не совсем комфортно жить в архитектуре, где транзакционные данные находятся в одной системе, аналитика — в другой, а между ними — разного рода ETL, CDC и прочие parquet‑файлы.

В Tantor мы движемся по иному пути, развивая HTAP внутри PostgreSQL, а не рядом с ним. Вокруг этой идеи строятся СУБД Tantor Polar и машина баз данных Tantor XData Gen3, в которой OLTP и аналитика, не теряя совместимости с Postgres, работают поверх общего хранилища данных и общей видимости транзакций. В этой статье хочется поговорить не столько о самом термине HTAP, сколько о том, как меняется архитектура PostgreSQL, когда OLTP и аналитика начинают работать поверх общего хранилища данных.

Один из первых сюрпризов при переходе с MS SQL на PostgreSQL состоит в отсутствии профайлера. Нет ни инструмента, ни аналога. Можно было бы поставить задачу команде разработки, но я решил попробовать поступить иначе, и за сутки, не написав ни строчки кода вручную, собрал работающий MVP с помощью ИИ. Рассказываю, как это было.

В обсуждении под статьями «СУБД Tantor Postgres 18: обзор улучшений для 1С» и «В погоне за APDEX‑ом, или как создать HighLoad на недорогом серверном железе» чрезвычайно уважаемые люди задались вопросом про *_collapse_limit и его отношение к geqo_threshold. В сообществе обсуждали эти параметры в большом топике, в этой статье коротко описано то, к чему там пришли.

Число 20 взялось из поста Роберта Хааса 2009 года по то, можно ли что‑то сделать с параметрами *_collapse_limit в PostgreSQL версии 8.5, которая в то время выходила.

Оператор OUTER JOIN — бич конфигураций 1С на базе PostgreSQL: планировщик пока небогат на оптимизации такого типа соединений. В то же время ORM-фреймворки — и 1С как яркий их представитель — часто генерируют внешние соединения по типовым шаблонам, что открывает возможности для точечной оптимизации.

В этой статье я разбираюсь с одним из таких шаблонов — разрешением полиморфных ссылок: что это за паттерн, откуда он берётся (Rails, Django, Hibernate, Salesforce — не только 1С), насколько он распространён и почему его структурные особенности позволяют существенно ускорить выполнение.

Уже совсем немного осталось до выхода релиза СУБД Tantor Postgres 18, и мы хотим наперед рассказать о его новых возможностях для работы с приложениями на платформе "1С:Предприятие". В обзоре разберем улучшения планировщика, по традиции коснемся работы временных таблиц и не обойдем вниманием вспомогательные утилиты, которые упрощают поиск и диагностику проблем в высоконагруженных системах. За каждым пунктом - реальные запросы 1С, реальные рабочие базы и сотни часов тестирования!

Группировка - это база OLAP. Но в интернете преступно мало информации о том, как это реализовано в PostgreSQL. Максимум, что вы сможете найти, - это CREATE AGGREGATE с функциями перехода или GROUP BY GROUPING SETS. А если спросить, как реализуется группировка, то в ответ получите - с помощью сортировки или созданием хэш-таблицы, но глубже вам вряд-ли кто-то что-то скажет.

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

Чтобы раскрыть завесу тайны и сделать жизнь других людей, решивших в это погрузиться, проще, в этой статье я описываю внутрянку модуля группировки: реализация агрегатов, разные стратегии группировки, поддержка GROUPING SETS и прочее. Помимо этого, как всегда, куча различных оптимизаций, неочевидные детали реализации и чуть-чуть истории. В конце опишу новую стратегию группировки - Index Aggregate.

Утилита резервирования pgBackRest перестала поддерживаться, стало актуальным найти ей замену. Главными альтернативами называют WAL-G и Barman. Можно использовать pg_basebackup+pg_receivewal. Преимущество WAL-G в том, что резервирование возможно по протоколу S3, WAL-G обеспечивает более высокую скорость резервирования и сжатия, имеет неплохие перспективы развития. Кроме протокола S3, WAL-G может резервировать и восстанавливать из директории в файловой системе, работает с Patroni. Директория с бэкапами не обязательно должна находиться на локальном диске, можно смонтировать любую файловую систему, например, NFS. Утилита свободно распространяемая.

В статье рассматриваются примеры команд, которыми можно резервировать и восстанавливать PostgreSQL утилитой WAL-G с обеспечением защиты от потерь транзакций (zero data loss).

Доверяем ли мы качеству OSS PostgreSQL? — выглядит он достойно. А насколько безопасны фичи, добавленные вендором? Это вопрос, поскольку код закрытый. Сила бренда — это хорошо, но хотелось бы иметь объективное подтверждение.

Здесь я рассказываю о небольшом изобретении — модуле pg_pathcheck. Он выводит на новый уровень контроль надёжности СУБД — позволяет проверять качество кода на стороне клиента. А конкретно, на его серверах и нагрузке проверить, не остаётся ли внутри оптимизатора так называемые dangling pointers — указателей вникуда. Это может не приводить к проблемам, пока оптимизатор не трогает эти указатели, но вот если таки тронет...

Одно из узких мест масштабируемости в традиционном PostgreSQL MVCC – получение снимков. Каждый раз, когда транзакции требуется снимок, она должна получить ProcArrayLock и пройтись по всем активным бэкендам, чтобы собрать их идентификаторы транзакций. Эта операция становится все более затратной по мере роста числа одновременных соединений: при тысячах соединений конкуренция за блокировку может серьезно ограничить пропускную способность. CSN (Commit Sequence Number) устраняет это узкое место, заменяя сканирование ProcArray атомарным чтением переменных, что делает получение снимков по сути O(1) независимо от количества соединений. В статье рассказывается о том, как технология работает в СУБД от «Тантор Лабс» и недавно представленной машине баз данных Tantor XData Gen3.

Эта история началась с подаренной коллегой своей новой книги: читая Jimmy Angelakos’ «PostgreSQL Mistakes and How to Avoid Them», я осознал один напрягающий меня факт — в Postgres команда EXPLAIN выдаёт слишком много информации. И примеры, которые автор обычно приводит, рассматривая тот или иной аспект систем баз данных, усложняют разбор задачи и рассеивают внимание. Так и родилась идея постфильтра для эксплейнов — чтобы сделать их более читабельными и проблемно-ориентированными.

Будучи поклонником идеи Айзека Азимова о коллаборации C/Si форм жизни, я провёл эксперимент и сгенерировал данный текст автоматически, AI агентом, по контексту, сформированному в процессе разработки новой фичи оптимизатора Postgres и расследования проблемного corner case, который время от времени завершался с runtime-ошибкой. Это первый опыт подобной совместной работы и проба пера, поэтому возможны шероховатости. Однако сама проблема и вариант решения для Postgres валидированы вручную. Любая, даже самая жёсткая критика, приветствуется.

При обновлении PostgreSQL с 17-й на 18-ю версию часть пользователей при работе с временными таблицами столкнулась с неожиданной ошибкой no empty local buffer available, в том числе, в типовых конфигурациях 1С. В статье разбираем первопричину: как новый механизм асинхронного prefetch в read stream конкурирует с insert stream за слоты local buffer pool, почему это не проявлялось в PostgreSQL 17, и какие исправления предложила сообществу PostgreSQL команда Tantor.