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

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

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

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

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

Мажорное обновление платформы Tantor 6.0: переработанный UI и интеграция с RuBackup

➡️ Полностью переработанный интерфейс: упрощены навигация и организация рабочего пространства. Все ключевые инструменты (SQL-редактор, анонимайзер, модули аналитики, мониторинга и другие) теперь доступны в едином блоке, а переключение на требуемый функционал стало более интуитивным. Добавлена гибкая настройка отображения столбцов таблиц и другие возможности

➡️ Обновлена ролевая модель доступа, поддерживающая разграничение прав на системном уровне (новая роль «Владелец системы») и на уровнях тенантов, администраторов и наблюдателей

➡️ Улучшения, облегчающие работу со сторонними сервисами: интеграция с системой резервного копирования, восстановления и защиты данных RuBackup позволяет просматривать все резервные копии в разрезах кластеров и инстансов с отметками о результате их создания, а подключение к корпоративному почтовому серверу для отправки уведомлений на e-mail теперь настраивается прямо в интерфейсе

↗️ Подробнее – в пресс-релизе.

#Tantor #TantorPostgres #ПлатформаTantor

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

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

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

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

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

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