Будучи поклонником идеи Айзека Азимова о коллаборации 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.

СУБД PostgreSQL давно закрепилась в топе благодаря открытости, надёжности и расширяемости, однако ее архитектурный консерватизм порождает ряд нерешённых проблем: отсутствие горизонтального масштабирования, деградация при тысячах соединений, узкое место WAL при высоком commit rate, невозможность полноценной HTAP-обработки и другие.

В статье рассказываем как в новом, третьем поколении машин баз данных Tantor XData Gen3 эти ограничения преодолеваются через глубокую переработку архитектуры — от полного разделения Compute и Storage с протоколом RDMA и распределённой файловой системой PFS до внедрения механизмов CSN для MVCC без блокировок, конвейерной обработки WAL и встроенного MPP‑движка, превращающего PostgreSQL в систему, способную конкурировать с Oracle Exadata уже по‑настоящему. И все это — со 100% сохранением совместимости с «обычным» PostgreSQL.

«Поднятие» унаследованного Postgres без специнструментов быстро превращается в головную боль: вас ждет ручной разбор схем, перелопачивание десятков таблиц и прочая невеселая археология - где лежат персональные данные, что за колонки, как это всё соотносится с 152-ФЗ… Один неверный шаг – и можно запросто упустить что-то важное. Встроенного защитного преобразования данных на диске нет, приходится либо городить огород на уровне приложений, либо создавать триггеры. Хранить ключи, тестировать производительность, поддерживать это всё, руками выставлять фильтры, думать, куда писать логи, как следить за аномалиями и так далее. Всё, что связано с безопасностью – проверять вручную. Любое изменение схемы — снова садись и аудируй заново. Времени уходить будет очень много, и неизвестно, какие грабли вылезут.

В СУБД Tantor Certified то, что обычно делается на коленке, превращается в понятный и безопасный процесс, который подробно описывается в статье.

Мы уже писали о нагрузочном тестировании машины баз данных Tantor XData 2Y на базе процессоров Intel, точнее, об успешно пройденном тесте на 30 тыс. пользователей 1С. Впечатляющие показатели — это прекрасно, однако реальность рынка enterprise-решений такова, что технические характеристики — не единственный критерий для выбора оборудования. Требования 398-ФЗ, стратегии импортозамещения, санкционные риски и бюджетные ограничения заставляют компании искать баланс между производительностью и другими факторами. 

В линейке Tantor XData есть модель 2B на базе процессоров Baikal-S, позиционируемая как ответ на подобные вызовы. В новой статье мы делимся результатами нагрузочного тестирования этой модели и рассказываем об особенностях работы ARM-архитектуры с PostgreSQL и практическом опыте оптимизации такой системы — со всеми техническими деталями, метриками производительности и найденными узкими местами.

Базы данных давно являются фундаментом цифровой экономики. От их архитектуры и производительности во многом зависят скорость вывода продуктов на рынок, стабильность сервисов и итоговая стоимость ИТ-инфраструктуры. В мировой практике одним из основных стандартов де-факто, вокруг которого формируются экосистемы серьезных решений, стала открытая СУБД PostgreSQL. В России она используется во множестве корпоративных приложений, есть целый ряд отечественных форков и дистрибутивов. Но у ряда зарубежных компаний( есть серьезные прорывные реализации, интенсивно развивающие Postgres (например, Aurora, AlloyDB и Neon, об этом ниже), а у российских этого почему-то не наблюдается. Это противоречие между массовым использованием PostgreSQL в нашей стране и отсутствием технологического прорыва задает остроту сегодняшней повестки отечественного СУБД-строения.

В статье рассматриваются текущие возможности горизонтального масштабирования СУБД для 1С, а также какое решение предлагает Tantor Postgres.

Однажды при мониторинге мы обратили внимание на запрос, который занимал первое место по длительности: 40+ секунд на выполнение при 657 вызовах за день. Причина состояла в том, что из-за неточной статистики распределения данных выбирался неподходящий индекс. В статье расскажем о том, как с помощью параметра STATMULTIPLIER в СУБД Tantor Postgres этот проблемный запрос удалось ускорить примерно в миллион раз — до 0.042 миллисекунды, — просто повысив точность статистики без изменения кода или структуры базы данных.

В PostgreSQL и Oracle Database команда UPDATE, столкнувшаяся с заблокированной строкой, ведёт себя по-разному. В статье рассматривается, как выполняется UPDATE в этих базах данных. Это может быть полезно при миграции кода приложения мжду этими базами данных.

Здесь я представляю результаты работы над первым шагом к внедрению временных таблиц в схему параллельного выполнения запросов в PostgreSQL - тестирование последовательной записи и чтения temp buffers. В системный каталог PostgreSQL добавлены функции измерения операций сброса буферов, и проведены тесты. Для целей оптимизатора выполнена оценка коэффициента стоимости сброса буфера временной таблицы на диск относительно уже существующего DEFAULT_SEQ_PAGE_COST. Выполнена оценка стоимости простого обхода temp buffers (dry-run). Измерения показывают, что последовательная запись примерно на 30% медленнее чтения. На основе этих результатов предложена формула оценки стоимости.

В статье речь пойдёт о методике разработки в Postgres, которую можно использовать для лучшей интеграции вашего расширения с базой данных. А конкретно - о том, как реализовать кастомные свойства объектов БД (или custom reloptions), которые можно было бы назначать разным типам объектов БД и таким образом управлять поведением расширения.

Привет, Хабр! Делимся переводом статьи о патче, сделанном разработчиком «Тантор Лабс» для 19 версии PostgreSQL — по сути, частичкой вклада нашей компании. Благодаря коммиту Ильи Евдокимова, в PostgreSQL 19 планирование JOIN’ов станет до 16 раз быстрее. Если раньше алгоритм сравнения частых значений (MCV) работал за O(N²), и при target=10k само планирование запроса могло занимать десятки миллисекунд, то теперь вместо квадратичного перебора будет использоваться хеш-таблица, а это снижает сложность до O(N). Изменение особенно оценят те, кто работает с неравномерными данными и поднимает default_statistics_target выше 1000.

Подробный разбор с тестами и графиками — в переводе статьи о нашем патче.

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

В статье рассматривается создание кластера Patroni последней версии 4.0.7 и etcd 3.6.5 в контейнерах docker. Приводится пример, когда Patroni не может автоматически восстановить и запустить кластер PostgreSQL. 

Patroni в докере

Задача запуска Patroni в докере обсуждалась на реддит и гитхаб. Приводился пример наиболее простой сборки batonogov/patroni-docker, которая состоит из 7 контейнеров: трёх с кластером etcd и трёх с PostgreSQL 17 под управлением Patroni (мастер и две реплики), один контейнер с HAProxy.

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

В статье будут рассмотрены основные методы хранения временных данных в PostgreSQL: обычные таблицы, нежурналируемые таблицы, материализованные преставления, временные таблицы и память серверного процесса с использованием расширения pg_variables.

В статье рассматривается логирование соединений с базами данных кластера PostgreSQL. Системы мониторинга создают сессии для сбора метрик и проверки доступности экземпляра. Это создаёт большое число записей в диагностическом журнале кластера, затрудняя его анализ. Администраторы ищут возможность отключения логирования для сессий мониторинга. Такая возможность есть только у параметра log_disconnections. Приводится пример, как с его помощью отключить логирование при создании сессии. Также рассматриваются особенности использования расширений pgaudit и pgaudittofile, которые позволяют выводить логирование соединений в отдельный файл аудита.

Если вы инженер в крупной компании, а особенно если ваша организация поставляет свои услуги в виде SaaS-решений, то вам так или иначе придется решать задачу мониторинга работы всех ваших баз PostgreSQL. На них часто бывает завязан функционал, важный для компании с точки зрения финансовых рисков, поэтому крайне желательно организовать не только мониторинг, но и получение уведомлений, когда что-то идет не по плану (или пойдет в ближайшем будущем). В рамках статьи мы рассмотрим несколько способов, как это можно сделать: самостоятельно, с использованием уже привычного стека Prometheus + Grafana, либо подключая сторонние open-source специализированные решения для мониторинга PostgreSQL, либо же используя специализированные платные решения. По каждому варианту поймем все плюсы и минусы, чтобы вы cмогли более уверенно выбрать свой путь.

Механизм реализации транзакций - основная часть реляционных баз данных. Он упрощает разработку приложений, в которых гарантируется целостность данных. Стандарт SQL регламентирует, часть свойств по поддержке транзакций, но многие детали не стандартизованы. Как следствие, реализация поддержки транзакций в разных базах данных может существенно различаться. В настоящее время, многие пытаются перейти с Oracle на PostgreSQL. Для миграции приложений важно понимать различия в реализации работы транзакций, иначе можно столкнуться с неприятными сюрпризами, которые могут поставить под угрозу производительность и целостность данных. Поэтому Лоренс Альбе решил, что полезно сравнить реализацию работы транзакций в Oracle и PostgreSQL и свести различия в одной статье.

Разбирая взаимоблокировки, Лоренс вспомнил, насколько опасным может быть использование SELECT FOR UPDATE при конкурентном доступе. В этом нет ничего нового, но Лоренс заметил, что многие не знают о режимах блокировки строк в PostgreSQL. Лоренс решил подробно описать, когда следует избегать SELECT FOR UPDATE.

Поводом для насписания статьи послужил доклад Евгения Воропаева "Разработка и отладка 64-битного счётчика транзакций" на конференции PG BootCamp 2025. При написании статьи была найдена реальная история патча и раскрыта тайна зоны special блоков PostgreSQL.

В статье описывается история создания патча, вводящего поддержку 64-битных номеров транзакций в PostgreSQL и почему он есть только в коммерческих форках. Статья особенно ценна тем, что под ней есть комментарий автора патча, Александра Короткова.