Перейти к основному содержимому

Оптимизация работы с временными таблицами

Сведения

Функциональность доступна только для редакций Enterprise и Enterprise для ERP-систем.

В данном разделе описаны механизмы оптимизации работы с временными таблицами, которые снижают нагрузку на файловую систему и системные каталоги, а также повышают эффективность обработки «краткоживущих» данных.

Отложенное размещение временных таблиц​

Для временных таблиц используется механизм отложенного создания файлов на диске, при котором данные первоначально размещаются в оперативной памяти и сбрасываются на диск только при исчерпании temp_buffers. Это позволяет снизить нагрузку на подсистему ввода-вывода при интенсивном использовании временных объектов.

Настройка​

Для активации функциональности необходимо установить GUC-параметр конфигурации:

SET deferred_temp_table_placement = on;

Или указать значение в postgresql.conf:

deferred_temp_table_placement = on

Применение данного параметра доступно только при запуске сервера.

Поведение​

При активной функциональности (включенном параметре deferred_temp_table_placement):

  • временные таблицы изначально полностью хранятся в памяти, используя выделенные temp_buffers бэкенд-процесса;
  • файлы на диске не создаются, пока в этом нет необходимости;
  • только в случае, если temp_buffers заполнены, СУБД начинает сбрасывать страницы временных таблиц на диск, чтобы освободить место для новых данных;
  • уменьшается количество операций ввода-вывода при кратковременном использовании временных таблиц.

Оптимизация при создании relfilenode​

Параметр check_temp_relfile_on_create управляет проверкой наличия файлов на диске при создании временных объектов.

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

При отключении проверки для временных объектов (с префиксом t_backendid и уникальным OID) запись файла выполняется напрямую. В результате сокращается количество системных вызовов и устраняется деградация производительности при массовом создании и удалении временных таблиц.

Мониторинг​

Для просмотра содержимого временного буфера текущего бэкенд-процесса можно использовать представление:

SELECT * FROM pg_buffercache_local;

Представление формируется расширением pg_buffercache и отражает страницы временных данных, находящиеся в локальном буфере текущего бэкенд-процесса.

Пример использования​

  • приложения, активно создающие и удаляющие множество временных таблиц, например при выполнении аналитических запросов или ETL-процессов;
  • сценарии, при которых отложенное размещение временных таблиц уменьшает общее количество операций записи и повышает скорость выполнения при работе с небольшими объемами данных.

Хранение метаданных временных объектов в памяти​

Функциональность позволяет не записывать метаданные о временных таблицах и индексах в pg_catalog. Это особенно полезно для приложений, активно создающих временные объекты, и позволяет избежать:

  • раздувания системных каталогов;
  • избыточной генерации WAL;
  • нагрузки на синхронную репликацию;
  • удержания длительных транзакций.

Вместо записи в системные каталоги вся информация о временных объектах хранится в памяти текущего бэкенд-процесса, полностью обходя системные таблицы.

Настройка​

Для включения функциональности используются параметры конфигурации:

  • enable_temp_memory_catalog (по умолчанию: off)

    При включении метаданные временных таблиц и индексов сохраняются в памяти бэкенд-процесса, а не в системных каталогах pg_catalog.

  • show_temp_catalog_entries (по умолчанию: off)

    При включении временные объекты, метаданные которых находятся в памяти, виртуально подставляются в результаты запросов к системным каталогам (например, SELECT * FROM pg_class), несмотря на отсутствие физических записей.

Методы изменения этих параметров:

  • изменение параметров конфигурации:

    • для одиночного экземпляра – в файле postgresql.conf с последующим перезапуском СУБД;
    • для кластерной конфигурации – в файле postgres.yml с последующим перезапуском СУБД;

  • установка в текущей сессии командой SET.

Пример:

SET enable_temp_memory_catalog = on;
SET show_temp_catalog_entries = on;
Внимание!

Функциональность работает только при включенном optimize_for_1c. При включении optimize_for_1c оба параметра включаются автоматически. Сброс параметра enable_temp_memory_catalog недоступен, пока включен параметр optimize_for_1c.

Внутренние детали и ограничения​

Отслеживание зависимостей через общую память​

Так как метаданные временных объектов не попадают в pg_depend, целостность зависимостей реализована отдельным механизмом:

  • информация о зависимостях временных объектов сохраняется в общей памяти;
  • это предотвращает удаление постоянных объектов (например, функций, используемых во временных функциональных индексах) другими бэкенд-процессами, не видящими этих зависимостей.

Защита от переполнения OID (OID wraparound)​

СУБД определяет свободные OID путем сканирования pg_class. При отсутствии информации о временных объектах в pg_class возможно повторное использование OID, что может привести к ошибкам.

Для предотвращения конфликтов OID:

  • все OID, используемые временными объектами в бэкенд-процессах, отслеживаются в общей памяти;
  • логика выделения новых OID учитывает занятые значения и пропускает их.