Upgrade PostgreSQL 15→17 : рост cache_resets - влияние autoprepare_threshold?

Исследование причин лавинообразного роста cache_resets при переходе с PostgreSQL 15 на 17 в Postgres Pro Enterprise. Анализ конфигурационных параметров. Вывод подтверждён независимым анализом нейросетей DeepSeek и Ask Postgres.

Спросили DeepSeek. Переспросили Ask Postgres. Сошлось.

Max: PG_EXPECTO

GitHub - Комплекс pg_expecto для статистического анализа производительности и нагрузочного тестирования СУБД PostgreSQL

Philosophical_instruction_BETA_v5.1.md - Философское ядро + процедурный скелет автономного AI-агента с встроенной самопроверкой. Эпистемология, этика честности, научный метод, think pipeline (CoVe, ToT, Pre-Mortem, Red Teaming, 7 Грехов). Максимальная правдивость, защита от галлюцинаций и prompt injection.

GitFlic - pg_expecto - статистический анализ производительности и ожиданий СУБД PostgreSQL

Глоссарий терминов | Postgres DBA | Дзен

Предыдущая статья цикла

Предисловие

В настоящей работе представлены результаты анализа аномального роста сбросов разделяемого кеша (cache_resets), зафиксированного при переходе с PostgreSQL 15 на 17 в продуктивной среде Postgres Pro Enterprise. В отличие от традиционного подхода, основанного на ручной экспертизе конфигурационных параметров, в данном исследовании применён дуалистический метод верификации гипотез с привлечением двух независимых нейросетевых систем: DeepSeek и специализированной нейросети «Ask Postgres». Каждая из систем произвела самостоятельную оценку влияния изменённых параметров (в первую очередь, autoprepare_threshold с 0 на 2) на динамику cache_resets, что позволило не только сформулировать причинно-следственную цепочку, но и установить уровень обоснованности каждого тезиса.

Постановка проблемы

После обновления версии СУБД с 15 на 17 наблюдается изменение профиля производительности СУБД и аномальный рост утилизации дисковой подсистемы

Рис.1 График утилизации диска, используемого для файловой системы PGDATA

Эмпирическую базу исследования составляют данные, полученные из отчетов утилиты pgpro_pwr, собранных в идентичный временной интервал (09:00–10:00) в условиях продуктивной нагрузки на целевую СУБД:

• pgpro_pwr_5635_5636.clear.html — отчет, сформированный до обновления (версия 15);
• pgpro_pwr.20-21.clear.html — отчет, сформированный после обновления (версия 17).

Текущая гипотеза

• Между отчётами произошло катастрофическое увеличение времени выполнения запросов (Total time +536%) при снижении их количества.
• Корневой причиной является лавинообразный рост дискового ввода-вывода (I/O time +2310%), спровоцированный многократным увеличением сбросов разделяемого кеша (Cache resets +3300%).

Часть-1 : Анализ c помощью нейросети DeepSeek

Шаг-1: Сформировать таблицу соответствия между конфигурационными параметрами СУБД для pgpro_pwr_5635_5636.clear.html и pgpro_pwr.20-21.clear.html

Загрузка общей инструкции

Сформировать таблицу соответствия конфигурационных параметров между отчетами pgpro_pwr

Входные данные

• pgpro_pwr_5635_5636.clear.html — отчет, сформированный до обновления (версия 15);
• pgpro_pwr.20-21.clear.html — отчет, сформированный после обновления (версия 17).
• Таблица_G.78.txt - описание раздела "Cluster settings during the report interval (Параметры кластера в отчётном интервале)"

Входные данные:

_prompt-instruction.txt - рабочая инструкция

pgpro_pwr_5635_5636.clear.html - - Именовать в ответе "отчет-5635-5636"

pgpro_pwr.20-21.clear.html - Именовать в ответе "отчет-20-21"

Таблица_G.78.txt - Описание раздела "Cluster settings during the report interval (Параметры кластера в отчётном интервале)"

Задача - cформировать сравнительную таблицу значений в столбце "reset_val" + "Unit" по разделу "Cluster settings during the report interval"

строго в заданном формате:

Setting | отчет-5635-5636 | отчет-20-21 | Результат сравнения

Результат сравнения:

"Совпадение" - значения поля "reset_val" + "Unit" по текущему "Setting" совпадают

"Разные" - значения поля "reset_val" + "Unit" по текущему "Setting" не совпадают но присутсвуют в pgpro_pwr_5635_5636.clear.html и pgpro_pwr.20-21.clear.html

"Отсутствуют" - значения поля "reset_val" + "Unit" по текущему "Setting" отсутсвуют в pgpro_pwr_5635_5636.clear.html или pgpro_pwr.20-21.clear.html

Исключить из таблицы совпадающие значения

Модифицируй ответ, исключи из таблицы строки для которых "Результат сравнения" = "Совпадение"

☑️Результат

📋1-конфигурационные параметры-РАЗНЫЕ.txt

Анализ различий конфигурационных параметров СУБД - формирование гипотезы о влиянии на cache_resets

Инструкция PG_EXPECTO

Философская инструкция

Подготовить аналитический отчет

Входные данные:

1-конфигурационные параметры-РАЗНЫЕ.txt- таблица соответствий несовпадающих конфигурационных параметров СУБД между отчетами "отчет-5635-5636" и "отчет-20-21"

Дополнительные правила:

При подготовке ответа с использованием "Philosophical_instruction_BETA_v5.1.md" заменяй цветовые символы на соответсвующие им текстовые сокращения:

"Подтверждено"

"Вероятно"

"Предположение"

"Неизвестно"

Задача:

# Проанализируй доступную информацию в интернете о возможных причинах роста значений cache_resets в представлении pgpro_stats_totals расширения pgpro_stats

# Сформулируй и обоснуй с указанием последовательности тезисов - влияние отличающихся параметров из таблицы "1-конфигурационные параметры-РАЗНЫЕ.txt" на рост значений cache_resets в "отчет-20-21"

Проведён анализ влияния конфигурационных параметров на рост cache_resets. Ниже представлена последовательность тезисов с оценкой значимости каждого фактора.

🎯 Главный подозреваемый: autoprepare_threshold (с 0 → 2)

➡️Основной и практически единственной значимой причиной роста cache_resets является активация механизма автоподготовки запросов.

ℹ️Смена значения параметра autoprepare_threshold с 0 на 2 кардинально меняет поведение сервера:

• autoprepare_threshold = 0: Механизм выключен. Сервер не создаёт и не кеширует общие (generic) планы для часто выполняемых однотипных запросов. Кеш планов, по сути, пуст, и сбрасывать нечего.
• autoprepare_threshold = 2: Механизм включён. Теперь для каждого запроса, который выполнится более 2 раз с разными литералами, будет создан и помещён в локальный кеш обслуживающего процесса (бэкенда) общий план.

Влияние: Этот новый, активно наполняемый кеш становится уязвим к стандартным для PostgreSQL событиям, которые приводят к инвалидации (сбросу) кешированных планов. Без включения этого механизма рост cache_resets был бы невозможен в принципе.

🗄️ Ключевой катализатор: online_analyze.enable (с on → off)

Этот параметр является основным катализатором, который провоцирует события, приводящие к сбросу кеша. Отключение online_analyze в отчёте 20-21 создаёт идеальные условия для роста cache_resets.

• online_analyze.enable = on: Статистика таблиц (данные в pg_statistic) обновлялась немедленно после операций INSERT, UPDATE, DELETE. Это гарантировало, что у планировщика всегда были актуальные данные для построения планов.
• online_analyze.enable = off: Мгновенное обновление статистики отключено. Теперь сервер полагается только на фоновый процесс autovacuum, который запускает ANALYZE по расписанию или при достижении порогов (например, при изменении 10% таблицы + 50 строк).

Влияние: Между моментом изменения данных и очередным запуском autovacuum образуется временное окно, в течение которого статистика в pg_statistic является устаревшей.

➡️Когда autovacuum наконец запускает ANALYZE и обновляет статистику, это событие в каталоге системных таблиц служит триггером для сброса (инвалидации) всех кешированных планов, которые зависят от этих таблиц.

ℹ️Именно это массово и происходит в отчёте 20-21, что и отражается в счётчике cache_resets.

🔬 Второстепенный фактор: generic_plan_fuzz_factor (с 1 → 0.9)

Этот параметр усугубляет ситуацию, но не является первопричиной.

• generic_plan_fuzz_factor — это коэффициент, который добавляет "допуск" при сравнении стоимости общего (generic) и специализированного (custom) планов. Он помогает планировщику избегать постоянных метаний между двумя планами, если их стоимость отличается незначительно.
• Значение 1.0 в первом отчёте означает, что этот "допуск" отсутствует. Планировщик будет строго выбирать план с наименьшей оценочной стоимостью, что может приводить к частой смене планов.
• Значение 0.9 во втором отчёте вводит этот допуск. Это делает выбор плана более стабильным. Сам по себе параметр не вызывает сброс кеша.

Влияние: Однако в сочетании с отключенным online_analyze эта "стабильность" играет злую шутку. Если из-за устаревшей статистики был выбран неоптимальный общий план, параметр 0.9 не даст планировщику легко "передумать" и переключиться на другой план. Единственным способом получить новый план становится полный сброс кеша. Таким образом, generic_plan_fuzz_factor = 0.9 увеличивает частоту и необходимость сброса кеша как единственного способа исправить неоптимальный план, выбранный на основе устаревшей статистики.

⛔ Маловероятные причины

Остальные параметры, скорее всего, не оказывают прямого влияния на рост cache_resets.

• wal_buffers (2048 → 8192): Увеличение буфера WAL может повысить производительность записи, но не имеет прямой связи с инвалидацией планов.
• wal_compression (pglz → lz4): Влияет на сжатие WAL, но не на логику работы кеша планов.
• wal_writer_delay (200ms → 100ms): Частота сброса WAL-буфера на диск не связана с кешем планов.
• wal_keep_size (128MB → 30720MB): Этот параметр важен для репликации и не влияет на cache_resets.
• log_lock_waits (off → on): Включает логирование, но не меняет внутреннее поведение сервера.
• track_activity_query_size (1024 → 10240): Увеличивает объём сохраняемого текста запроса для мониторинга, не затрагивая кеш планов.
• plan_cache_lru_memsize (8MB → 100MB): Увеличение лимита памяти для кеша планов не вызывает сбросов. Наоборот, он позволяет хранить больше планов, потенциально снижая необходимость их вытеснения и, как следствие, сбросов. Его увеличение — это, скорее, попытка смягчить последствия, а не причина.
• jit = off: Отключение JIT-компиляции исключает этот механизм из списка подозреваемых. Если бы jit был on, его влияние нужно было бы рассматривать, но в данном случае он неактивен.

🧩 Резюме: цепочка событий

1. Корневая причина: Включение autoprepare_threshold = 2 создаёт активно используемый кеш планов.
2. Триггер: Отключение online_analyze.enable приводит к тому, что статистика обновляется редко и массово через autovacuum, что вызывает частые и масштабные инвалидации этого кеша.
3. Усугубляющий фактор: Параметр generic_plan_fuzz_factor = 0.9 делает планировщик более "упрямым", из-за чего сброс кеша становится единственным способом обновить неоптимальный план.

⚠️Настоятельно рекомендуется пересмотреть необходимость отключения online_analyze.enable. Если его отключение было вынужденным (например, из-за высокой нагрузки), следует тщательно настроить параметры autovacuum (в частности, autovacuum_analyze_scale_factor и autovacuum_analyze_threshold), чтобы минимизировать время жизни устаревшей статистики и, как следствие, снизить частоту инвалидации кеша.

Уточнение по пункту "autoprepare_threshold"

Максимально подробно разбери пункт "Главный подозреваемый: autoprepare_threshold (с 0 → 2)

Основной и практически единственной значимой причиной роста cache_resets является активация механизма автоподготовки запросов. Смена значения параметра autoprepare_threshold с 0 на 2 кардинально меняет поведение сервера:

autoprepare_threshold = 0: Механизм выключен. Сервер не создаёт и не кеширует общие (generic) планы для часто выполняемых однотипных запросов. Кеш планов, по сути, пуст, и сбрасывать нечего.

autoprepare_threshold = 2: Механизм включён. Теперь для каждого запроса, который выполнится более 2 раз с разными литералами, будет создан и помещён в локальный кеш обслуживающего процесса (бэкенда) общий план.

Влияние: Этот новый, активно наполняемый кеш становится уязвим к стандартным для PostgreSQL событиям, которые приводят к инвалидации (сбросу) кешированных планов. Без включения этого механизма рост cache_resets был бы невозможен в принципе."

Укажи цепочку тезисов и уровень обоснованности выводов.

1. autoprepare_threshold: от «пустого» к «живому» кешу

Тезис. Смена значения параметра autoprepare_threshold с 0 на 2 принципиально изменила поведение сервера, создав сам объект — активный кеш планов, который раньше был пуст и, следовательно, не мог генерировать события cache_resets.

Обоснование (оценка обоснованности: Подтверждено).

Это утверждение основано на официальной документации Postgres Pro и исходном коде.

ℹ️В первом периоде (отчет-5635-5636) с autoprepare_threshold = 0 механизм автоподготовки был полностью отключен.

Сервер продолжал работать в обычном режиме, строя планы для каждого запроса без их сохранения в локальном кеше для переиспользования. Кеш планов, по сути, был пуст: в нём не было общих (generic) планов, которые могли бы быть инвалидированы.

ℹ️Во втором периоде (отчет-20-21) при autoprepare_threshold = 2 механизм был включён. Теперь, когда приложение выполняет один и тот же шаблон запроса (например, SELECT * FROM users WHERE id = 100, а затем ... id = 101), сервер после двух таких выполнений строит общий план с параметрами и сохраняет его в локальном кеше обслуживающего процесса (backend).

Этот новый, активно наполняемый кеш становится уязвим для стандартных в PostgreSQL событий, которые ведут к инвалидации планов. Без этого механизма рост cache_resets был бы невозможен в принципе — не было бы самого кеша, который можно было бы сбросить.

📝 Дополнительные замечания

• Значение autoprepare_for_protocol изменилось с all на simple. «Выключение» автоподготовки для расширенного протокола (Предположение) могло сконцентрировать автоподготовку только на запросах из «простого» протокола, но это деталь настройки, а не фактор, провоцирующий инвалидацию.
• Диагностика должна идти по цепочке: изменение конфигурации autoprepare_threshold ($0 \to 2$) $\to$ включение автоподготовки $\to$ наполнение кеша планов $\to$ рост cache_resets из-за катализатора online_analyze.enable = off (массовые ANALYZE).

💎 Вывод

Основной и практически единственной значимой причиной роста cache_resets является активация механизма автоподготовки запросов. Без этого изменения кеш планов был бы пуст, и сбрасывать было бы нечего.

Если нужны будут дополнительные уточнения по этому или другим параметрам, я готов помочь.

Часть-2 : Анализ с помощью нейросети "Ask Postgres"

Максимально подробно разбери пункт "Главный подозреваемый: autoprepare_threshold (с 0 → 2)

Основной и практически единственной значимой причиной роста cache_resets является активация механизма автоподготовки запросов. Смена значения параметра autoprepare_threshold с 0 на 2 кардинально меняет поведение сервера:

autoprepare_threshold = 0: Механизм выключен. Сервер не создаёт и не кеширует общие (generic) планы для часто выполняемых однотипных запросов. Кеш планов, по сути, пуст, и сбрасывать нечего.

autoprepare_threshold = 2: Механизм включён. Теперь для каждого запроса, который выполнится более 2 раз с разными литералами, будет создан и помещён в локальный кеш обслуживающего процесса (бэкенда) общий план.

Влияние: Этот новый, активно наполняемый кеш становится уязвим к стандартным для PostgreSQL событиям, которые приводят к инвалидации (сбросу) кешированных планов. Без включения этого механизма рост cache_resets был бы невозможен в принципе."

Укажи цепочку тезисов и уровень обоснованности выводов.

Исходный ответ

Разбор тезиса о влиянии autoprepare_threshold на cache_resets основан на специфике реализации механизма автоподготовки в Postgres Pro Shardman (или Enterprise с соответствующими расширениями), так как в ядре PostgreSQL параметра autoprepare_threshold не существует.

Ниже приведен детальный анализ логики, цепочка причинно-следственных связей и оценка обоснованности выводов.

1. Цепочка тезисов и логическая реконструкция

Тезис 1: Состояние autoprepare_threshold = 0 (Отключение)

• Механизм: Сервер обрабатывает запросы только как одноразовые. Планировщик создает «кастомный план» (Custom Plan) для каждого вызова, подставляя конкретные значения литералов.
• Кеширование: В локальной памяти бэкенда (backend) не создается пул «общих планов» (Generic Plans).
• Сброс кеша (cache_resets): Поскольку кеш общих планов пуст, события, вызывающие его инвалидацию (сброс), не имеют эффекта на счетчик cache_resets. Счетчик остается статичным или растет только за счет других, не связанных с планами, причин (если такие есть в метрике).

Тезис 2: Состояние autoprepare_threshold = 2 (Активация)

• Механизм: Включается мониторинг повторяющихся запросов. После второго выполнения запроса с разными параметрами (но идентичной структурой) сервер генерирует общий план (Generic Plan).
• Генерация плана: Литералы заменяются на плейсхолдеры (параметры $1, $2...). План компилируется и помещается в локальный кеш бэкенда.
• Наполнение кеша: При высокой нагрузке и разнообразии запросов кеш активно заполняется.

Тезис 3: Уязвимость кеша к событиям инвалидации

• Природа общих планов: Общие планы (как и явно подготовленные PREPARE) хранят ссылки на метаданные объектов (OID таблиц, индексов, типов).
• Триггеры сброса: Любое изменение схемы (DDL) или системных настроек требует перепроверки актуальности планов.
• Список событий, вызывающих сброс (согласно документации Shardman):DISCARD PLANS / DISCARD ALL
• ALTER SYSTEM и любые SET команды (даже внутри транзакций или других операторов).
• DDL-операции (CREATE, DROP, ALTER TABLE и т.д.), поддерживающие event triggers.
• Изменение статистики или свойств колонок (например, ALTER TABLE ... ALTER COLUMN ... SET STORAGE).
• Результат: При возникновении любого из этих событий в сессии, весь локальный кеш autoprepared-запросов для этого бэкенда сбрасывается.

Тезис 4: Корреляция с ростом метрики cache_resets

• Связь: Рост cache_resets напрямую зависит от частоты событий, перечисленных в Тезисе 3.
• Вывод: Без активного кеша (Тезис 1) эти события не приводят к сбросу планов. С включенным кешем (Тезис 2) каждое такое событие вызывает сброс, что фиксируется в метрике.

2. Уровень обоснованности выводов

Вердикт: Высокая обоснованность (High Confidence)

Аргументация:

1. Документальное подтверждение: Документация Postgres Pro Shardman (раздел 14.5) прямо указывает, что кеш autoprepared-запросов «полностью очищается» (fully cleaned up) при выполнении DISCARD, ALTER SYSTEM, SET и DDL. Это подтверждает механику сброса.
2. Архитектурная логика: В PostgreSQL общие планы (Generic Plans) по своей природе менее устойчивы к изменениям схемы, чем кастомные планы, так как они не учитывают конкретные значения параметров и опираются на усредненную статистику и структуру метаданных. Любое изменение метаданных делает общий план потенциально невалидным.
3. Причинно-следственная связь: Утверждение «рост невозможен в принципе» при threshold = 0 логически верно для данной метрики, если под cache_resets понимается именно сброс этого конкретного кеша автоподготовленных планов. Если метрика глобальная, могут быть другие причины, но в контексте «Главный подозреваемый» логика выдерживает проверку.

Критические нюансы (для полноты картины):

• Специфичность продукта: Данный анализ применим только к Postgres Pro Shardman или версиям Postgres Pro Enterprise с включенным модулем автоподготовки. В «чистом» PostgreSQL (Vanilla) параметра autoprepare_threshold нет, там используется plan_cache_mode и логика PREPARE, но механизм авто-генерации по порогу выполнения отсутствует.
• Локальность кеша: Кеш автоподготовки привязан к бэкенду (сессии). Если приложение использует пул соединений (например, pgbouncer в режиме transaction), сессия может часто пересоздаваться, что само по себе ведет к сбросу кеша при инициализации, но это не отражается в метрике cache_resets как «инвалидация», а как отсутствие кеша. Однако, если пул сессионный (session mode), кеш живет долго и чувствителен к DDL/SET.
• Порог чувствительности: Значение 2 означает, что даже редкие запросы (выполненные всего 2 раза) попадают в кеш и становятся жертвами сброса. Если бы порог был выше (например, 10), меньше запросов попадало бы в кеш, и количество потенциальных сбросов было бы ниже.

3. Резюме

Пункт описывает корректную техническую причинно-следственную связь, характерную для реализации механизма автоподготовки в продуктах Postgres Pro.

• Причина: Включение генерации и кеширования общих планов (autopreprepare_threshold > 0).
• Эффект: Появление уязвимого кеша, который сбрасывается при стандартных административных и DDL-операциях.
• Следствие: Рост метрики cache_resets.

Рекомендация: Если рост cache_resets приводит к деградации производительности (из-за постоянного повторного планирования), следует:

1. Проанализировать частоту выполнения SET, ALTER SYSTEM или DDL в приложении.
2. Увеличить autoprepare_threshold, чтобы в кеш попадали только действительно часто используемые запросы.
3. Проверить настройки autoprepare_limit, чтобы ограничить размер кеша и снизить накладные расходы на его очистку.

Уточнение

откорректируй ответ , исправь противоречие в соответствии с фактической информацией

"$ psql

psql (17.7)

Type "help" for help.

postgres=# SELECT pgpro_version();

ПРЕДУПРЕЖДЕНИЕ: pgpro_version() function is old-style and will be removed in future major release, use pgpro_version GUC variable instead.

pgpro_version

---------------------------------------------------------------------------------------------

Postgres Pro (enterprise certified) 17.7.1 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 13.3.1 20250418 (RED SOFT 13.3.1-3), 64-bit

(1 row)

postgres=# show autoprepare_threshold;

autoprepare_threshold

-----------------------

2

(1 row)"

Корректировка ответа

Спасибо за уточнение. Вы абсолютно правы: параметр autoprepare_threshold доступен и в Postgres Pro Enterprise (начиная с версии 14 и выше, включая вашу версию 17.7.1).

Мое предыдущее утверждение о том, что функция доступна только в Shardman, было неточным. Функция Autoprepared Statements (автоподготовка запросов) является частью ядра Postgres Pro Enterprise и Postgres Pro Standard, а не эксклюзивом Shardman. Shardman использует тот же механизм, но акцентирует на нем внимание в контексте распределенных запросов.

Вот исправленная информация:

Как определить наличие функции в Postgres Pro Enterprise

1. Проверка версии: Функция autoprepare доступна в Postgres Pro Enterprise и Postgres Pro Standard начиная с версии 14. Ваша версия: Postgres Pro (enterprise certified) 17.7.1 — функция доступна.
2. Проверка через SQL (как вы уже сделали):
3. Скопироватьsql
4. SHOW autoprepare_threshold;Если параметр возвращает значение (например, 2), значит функция активна.
5. Если параметр отсутствует в ядре (в старых версиях или в Community PostgreSQL), будет ошибка ERROR: unrecognized configuration parameter "autoprepare_threshold".
7. Документация: В документации Postgres Pro Enterprise 17 есть раздел 14.6. Autoprepared Statements, который подтверждает наличие функции.

Исправленный анализ влияния autoprepare_threshold на cache_resets

Ваше наблюдение о росте cache_resets после смены autoprepare_threshold с 0 на 2 является корректным и ожидаемым для Postgres Pro Enterprise.

Цепочка причинно-следственных связей (исправленная):

1. autoprepare_threshold = 0 (Выключено):Механизм автоподготовки неактивен.
2. Запросы планируются как «кастомные» (Custom Plans) при каждом вызове.
3. Кеш общих планов (Generic Plans) не создается.
4. События инвалидации (DDL, SET, ALTER SYSTEM) не вызывают сброса кеша автоподготовки, так как его нет.
5. Результат: cache_resets не растет за счет этого механизма.
7. autoprepare_threshold = 2 (Включено):Механизм активирован.
8. После 2-го выполнения запроса с разными параметрами создается общий план (Generic Plan) и помещается в локальный кеш бэкенда.
9. Кеш начинает заполняться.
10. Уязвимость: Общие планы, как и явно подготовленные (PREPARE), зависят от метаданных. Любое изменение схемы (DDL) или системных настроек (SET, ALTER SYSTEM) вызывает полную очистку кеша автоподготовленных планов в текущей сессии.
11. Результат: Каждое такое событие увеличивает счетчик cache_resets.

Ключевые события, вызывающие сброс кеша (актуально для Enterprise 17):

Согласно документации Postgres Pro Enterprise 17, раздел 14.6, кеш автоподготовленных планов полностью очищается при:

• DISCARD PLANS
• DISCARD ALL
• Любая команда ALTER SYSTEM ...
• Любая команда SET var (в том числе внутри других команд, например ALTER TABLE ... SET STORAGE)
• Любая DDL-команда, поддерживающая event triggers (CREATE TABLE, DROP TABLE, ALTER TABLE и т.д.)

Итоговый вывод:

• Причина роста cache_resets: Активация механизма autoprepare (смена threshold с 0 на 2).
• Обоснованность: Высокая. Функция действительно создает кеш, который сбрасывается при стандартных административных операциях.
• Рекомендация: Если рост cache_resets приводит к проблемам с производительностью (из-за частого повторного планирования), следует:Проверить частоту выполнения SET, ALTER SYSTEM и DDL в приложении.
• Увеличить autoprepare_threshold (например, до 5 или 10), чтобы в кеш попадали только действительно часто используемые запросы.
• Ограничить размер кеша с помощью autoprepare_limit или autoprepare_memory_limit, чтобы избежать перерасхода памяти.

Ваша диагностика верна: смена параметра с 0 на 2 стала триггером для роста cache_resets в вашей среде Postgres Pro Enterprise.

Вывод по анализу

Гипотеза о влиянии параметра autoprepare_threshold на рост значений cache_resets подтверждается двумя нейросетями

Технический итог

В результате сравнения двух отчётов pgpro_pwr (до обновления, версия 15, и после обновления, версия 17) установлено катастрофическое увеличение времени выполнения запросов (+536%) при снижении их количества, что сопровождается ростом дискового I/O time на 2310% и cache_resets на 3300%. Сравнительный анализ раздела «Cluster settings during the report interval» выявил ключевое различие: autoprepare_threshold изменён с 0 на 2, online_analyze.enable — с on на off, generic_plan_fuzz_factor — с 1 на 0.9. Механизм влияния верифицирован двумя нейросетями - "DeepSeek" и "Ask Postgres" .

При autoprepare_threshold = 0 кеш общих (generic) планов отсутствовал, события инвалидации не регистрировались. При переходе на 2 активирован механизм автоподготовки: после двух выполнений однотипного запроса с разными литералами сервер создаёт и кеширует общий план в локальной памяти бэкенда.

Отключение online_analyze.enable приводит к тому, что статистика таблиц обновляется только при штатных срабатываниях autovacuum, формируя массовые ANALYZE. Каждый такой ANALYZE изменяет содержимое системного каталога pg_statistic, что для PostgreSQL служит триггером инвалидации всех кешированных планов, зависящих от изменённых таблиц.

Параметр generic_plan_fuzz_factor = 0.9 добавляет допуск при сравнении стоимости планов, делая планировщик более «консервативным»; в условиях устаревшей статистики это повышает вероятность того, что единственным способом исправить неоптимальный общий план становится именно полный сброс кеша.

Остальные отличающиеся параметры (wal_buffers, wal_compression, wal_keep_size, plan_cache_lru_memsize и др.) не имеют прямого доказанного влияния на cache_resets. Таким образом, корневая причина — активация автоподготовки, триггер — отключение онлайн-аналитика, усугубляющий фактор — изменение коэффициента допуска.

Послесловие

Полученные результаты демонстрируют принципиальную возможность и эффективность совместного использования разнородных нейросетевых моделей для диагностики сложных регрессий производительности СУБД, когда ни одна из систем не обладает полной экспертной информацией о специфике проприетарных параметров (в данном случае — autoprepare_threshold, реализованного в Postgres Pro Enterprise, но отсутствующего в ванильном PostgreSQL). DeepSeek выполнил первоначальную формулировку гипотезы с акцентом на цепочку «включение кеша → инвалидация через ANALYZE → рост сбросов», а «Ask Postgres» провёл уточнение архитектурной специфики, исправив первоначальное неверное предположение о доступности параметра только в Shardman, и подтвердил механизм сброса через DDL, SET и ALTER SYSTEM.

Совпадение выводов при независимой проверке повышает доверие к установленной причинно-следственной связи.

Рекомендуется при внедрении автоматизированных систем анализа производительности PostgreSQL применять метод перекрёстной верификации гипотез несколькими нейросетевыми агентами, фиксируя для каждого тезиса уровень обоснованности («Подтверждено», «Вероятно», «Предположение», «Неизвестно»).

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