Сегодня мы запустили корпоративный блог Tantor 🌚 на Habr!


Первой публикацией стала статья: «Как избежать ошибок памяти при работе с большими данными в PostgreSQL?».

Если вы администрируете PostgreSQL-кластеры или работаете с объёмными данными (XML-документы, конфигурации 1С и др.), вы могли столкнуться с ошибкой ERROR: out of memory при выгрузке таблиц через pg_dump или команду COPY. В дебютном материале мы разбираем причины этой проблемы и предлагаем решения, включая особый параметр из арсенала СУБД Tantor Postgres — enable_large_allocations.

О чем мы рассказываем в статье:
➡️ Почему даже данные меньше 1 ГБ могут вызвать сбой при выгрузке.
➡️ Как экранирование символов «раздувает» размер строк и приводит к ошибкам.
➡️ Решение Tantor Postgres — увеличение лимита буфера до 2 ГБ и оптимизация процессов.

Статья будет полезна администраторам БД, разработчикам и всем, кто работает с PostgreSQL в высоконагруженных средах.

↗️ Читайте первый материал нашего блога на Habr по ссылке.

#PostgreSQL #TantorPostgres #Tantor #Администрирование #Habr

Быстрый старт в маскировании данных с pg_anon

Маскирование данных — это не только про звездочки вместо букв. Это может касаться имён, телефонов, номеров карт, медицинских диагнозов и другой чувствительной информации. Если ваша компания до сих пор передает данные подрядчикам или аналитикам как они есть в базе, это в один «прекрасный» момент обязательно обернётся проблемой.

Чтобы избежать финансовых и репутационных рисков, в работе с БД обязательно нужны гибкие инструменты обезличивания. Один из них — разработанный нами opensource-инструмент pg_anon. Он маскирует конфиденциальные данные, помогая соблюдать закон, защищая информацию и сохраняя её пригодность для анализа.

В новой статье в нашем блоге на Habr:

➡️ Разберем разработанный нами бесплатный инструмент от установки до использования
➡️ Создадим словарь анонимизации
➡️ Снимем дамп с маскированием и проверим результат!


↗️Читать статью

#Tantor #TantorPostgres #1C #Anonimization #Habr #Tantor1C

Вечер пятницы. Время отвлечься от работы и… почитать про PostgreSQL.

Наша новая статья на HABR посвящена внутристраничной очистке для индексов. Если вы DBA или разработчик и хотите лучше разбираться в тонкостях работы Tantor Postgres и других СУБД на базе PostgreSQL на низком уровне, понимать возможные причины замедлений, – эта статья для вас.

Что исследуем:
➡️ Принцип работы: Как PostgreSQL удаляет устаревшие версии строк (MVCC) из индексных страниц для эффективного повторного использования пространства
➡️ Ключевое ограничение: Очистка возможна только для версий, вышедших за горизонт базы данных (xmin horizon)
➡️Проблема удержания горизонта: Что происходит, если в системе есть долгая транзакция или запрос? Как это блокирует очистку как внутристраничную, так и VACUUM
➡️ Последствия для производительности: На реальном примере pgbench показываем, как удержание горизонта транзакцией или запросом приводит к тому, что новые версии строк вынуждены размещаться в новых блоках индекса, и это сильно снижает производительность поиска по индексу актуальной версии строки (процесс вынужден просматривать все версии строк).

↗️Читать статью

#Tantor #TantorPostgres #Habr

Когда pg_stat_statements замедляет вашу БД? Разбираем сэмплирование!

Сбор статистики SQL-запросов (количество запусков, общее и среднее время их выполнения, число возвращённых строк и др.) позволяет анализировать их поведение во времени, выявлять проблемные участки и принимать обоснованные решения по оптимизации. Но знаете ли вы, что расширение pg_stat_statements, которое помогает собирать такую статистику, само может стать узким местом и вызывать просадки производительности?

К выпуску СУБД Tantor Postgres 17.5.0 мы запускаем серию публикаций в нашем корпоративном блоге на Habr о наиболее интересных новинках релиза. В сегодняшней статье на практических примерах разбираем:

➡️ В каких сценариях расширение pg_stat_statements становится источником проблем
➡️ Как устроено сэмплирование и в каких случаях его применение позволяет снизить «накладные расходы»
➡️ Как сэмплирование реализовано в СУБД Tantor Postgres 17.5.0

Статья будет полезна администраторам высоконагруженных кластеров PostgreSQL, столкнувшимся с деградацией производительности из-за pg_stat_statements и всем, кто работает над оптимизацией своих систем.

↗️Читайте статью

#Tantor #TantorPostgres #Habr

Настройка OAuth-авторизации в Tantor Postgres 17.5 и PostgreSQL 18: практическое руководство на примере Keycloak

Мы продолжаем цикл статей, в которых описываем нововведения СУБД Tantor Postgres 17.5.0. В прошлый раз мы писали об оптимизации нагрузки на систему за счет сэмплирования сбора статистики с pg_stat_statements. Сегодня хотим спросить — знаете ли вы, что Tantor Postgres 17.5.0 поддерживает авторизацию по OAuth 2.0 Device Authorization Flow (эта же возможность ожидается в PostgreSQL 18)? Это позволяет отказаться от паролей на клиенте и централизовать управление доступом через провайдеров.

В новой статье в нашем блоге на Habr — детальное руководство по реализации авторизации OAuth 2.0 на примере Keycloak:
➡️Настройка Keycloak как провайдера идентификации (Realm, Users, Client scopes, Clients)
➡️Подготовка PostgreSQL (настройка pg_hba.conf, pg_ident.conf, параметра oauth_validator_libraries)
➡️Реализация валидатора токенов на C с обработкой JWT и проверкой scope
➡️Процесс авторизации через psql с использованием Device Flow

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

↗️Читать статью

#Tantor #TantorPostgres #PostgreSQL #OAuth #Habr

Как создаются патчи для PostgreSQL?

Разработчикам, расширяющим функционал PostgreSQL, иногда требуется добавлять в существующие команды новые параметры. Однако порядок модификации исходного кода — подчас непростая задача:
➡️Где взять списки файлов, в которые нужно вносить изменения?
➡️В какие места в этих файлах их вносить?
➡️Какой, собственно, вносить код?
➡️Как повысить шансы на принятие патча сообществом?

В новой статье «Пример создания патча для PostgreSQL» в корпоративном блоге Tantor на Habr детально разбирается процесс такого рода доработки на примере добавления нового колоночного атрибута в системный каталог, с возможностью установки значения через команду ALTER TABLE.

Статья написана по реальному кейсу, описанному одним из наших разработчиков в докладе на конференции PG BootCamp 2025 в Екатеринбурге, и может служить своего рода руководством.

↗️Читать статью

#Tantor #TantorPostgres #Habr

pg_dphyp: учим PostgreSQL соединять таблицы по другому

Планировщик PostgreSQL предлагает оптимальный способ соединения таблиц, опираясь на алгоритмы DPsize (динамическое программирование) и GEQO (генетическая эвристика). Мы задались вопросом: а что если взять алгоритм DPhyp, основанный на гиперграфах и реализованный в некоторых других СУБД, и «вшить» его в PostgreSQL без правок ядра?

В нашей новой статье на Habr – подробный R&D-отчёт о прототипировании расширения pg_dphyp, реализующего этот алгоритм. В центре попытки его создать — задача реализации преимуществ гиперграфного подхода без изменения существующей инфраструктуры планировщика. В результате в одном из тестов удалось ускорить планирование конкретного сложного JOIN-запроса в 600 раз.

Кейс показал, что DPhyp способен не просто разнообразить арсенал PostgreSQL, но в отдельных сценариях прирастить производительность. Недостатки у алгоритма есть, но значит, есть и пространство для будущих размышлений и исследований!

↗️Читайте статью в нашем блоге на Habr

#Tantor #Habr

Механизм работы временных таблиц PostgreSQL и его влияние на таблицы системного каталога

При создании и удалении временных таблиц в PostgreSQL изменяются до 13 таблиц системного каталога, при этом особенно сильно разрастаются pg_attribute, pg_class и pg_depend. Массовое создание и усечение временных таблиц активно применяется в том числе в 1C:ERP.

В нашей новой статье в блоге на Habr — разбор механизмов и особенностей работы с временными таблицами: мониторинг роста, работа автовакуума, замеры падения производительности и нагрузок на буферный кэш. Особое внимание уделено решению этой проблемы в СУБД Tantor Postgres 17.5: параметр enable_temp_memory_catalog переносит метаданные временных таблиц в память процесса, исключая изменения в системных таблицах. Результаты тестов показывают стабильную работу без падения производительности.

↗️Читать статью

#Habr #TantorPostgres #Производительность #Tantor1C

Почему PostgreSQL иногда делает «неправильный» выбор индекса — и как это исправить?

Бывает так, что после миграции «1С» на Postgres часть запросов внезапно начинает работать в разы медленнее из-за того, что когда есть несколько индексов с одинаковыми ведущими столбцами, планировщик выбирает не самый подходящий. Типичная ситуация: есть «широкий» индекс, покрывающий все условия запроса, и «узкий», обслуживающий другие запросы, и планировщик выбирает узкий, потому что его стоимость представляется более низкой. Это приводит к избыточному чтению данных и многократному увеличению времени выполнения.

В свежей статье на Хабре подробно разбираем, как PostgreSQL оценивает стоимость индексного доступа, в каких формулах кроется подвох, почему селективность может быть «запредельной». Показываем, как можно использовать расширенную статистику и что даёт наш патч, который исправляет выбор индекса в Tantor Postgres 17.5.

Если вам интересна работа планировщика и технические детали работы индексов — читайте статью. Она поможет понять, почему "всё медленно", когда всё вроде бы правильно.

↗️Читать статью

#TantorPostgres #PostgreSQL #1C #Производительность #Habr