72 подписчика

Upgrade PostgreSQL 15→17 : Сравнительный аналитический отчёт pgpro_pwr.

15 апреля15 апр

23 мин

[ℹ️Первый случай проблем после upgradeℹ️] Целью исследования является формирование аналитического отчёта по сравнению профилей нагрузки PostgreSQL версий 15.14.1 и 17.9.2. Анализ выполняется на основе отчётов pgpro_pwr с применением доменной методологии PG_EXPECTO. В ходе работы предусмотрено выявление ключевых различий в конфигурации, структуре запросов, уровне использования центрального процессора (CPU), объёме временных файлов и интенсивности генерации WAL. Завершающим этапом выступает формулирование гипотез о причинах наблюдаемого роста утилизации CPU. Max: PG_EXPECTO GitHub - Комплекс pg_expecto для статистического анализа производительности и нагрузочного тестирования СУБД PostgreSQL Philosophical_instruction_BETA_v5.1.md - Философское ядро + процедурный скелет автономного AI-агента с встроенной самопроверкой. Эпистемология, этика честности, научный метод, think pipeline (CoVe, ToT, Pre-Mortem, Red Teaming, 7 Грехов). Максимальная правдивость, защита от галлюцинаций и prompt inje

Оглавление

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

[ℹ️Первый случай проблем после upgradeℹ️]

Целью исследования является формирование аналитического отчёта по сравнению профилей нагрузки PostgreSQL версий 15.14.1 и 17.9.2. Анализ выполняется на основе отчётов pgpro_pwr с применением доменной методологии PG_EXPECTO. В ходе работы предусмотрено выявление ключевых различий в конфигурации, структуре запросов, уровне использования центрального процессора (CPU), объёме временных файлов и интенсивности генерации WAL. Завершающим этапом выступает формулирование гипотез о причинах наблюдаемого роста утилизации CPU.

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 | Дзен

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

PG_EXPECTO 8.1: аналитический отчёт по результатам нагрузочного тестирования PostgreSQL.

Postgres DBA14 апреля

Предисловие

Настоящий отчёт представляет собой результат применения доменной методологии PG_EXPECTO в связке с философской инструкцией (эпистемический протокол, направленный на максимизацию правдивости и защиту от галлюцинаций) для сравнительного анализа двух часовых профилей производительности PostgreSQL. Исходными данными послужили отчёты pgpro_pwr, сформированные на продуктивной СУБД до обновления (Postgres Pro Enterprise 15.14.1, период 11989–11995) и после обновления (Postgres Pro Enterprise 17.9.2, период 289–295). Ключевой акцент сделан на анализе причин изменения утилизации CPU, а также на выявлении различий в конфигурации, структуре нагрузки, использовании временных файлов и генерации WAL. Все выводы строго разделены по уровням достоверности — от подтверждённых данными до требующих дополнительной проверки.

Задача

Проанализировать результаты применения доменной инструкции pg_expecto и философской инструкции для формирования аналитического сравнительного отчета pgpro_pwr, с акцентом на анализ причин изменения утилизации CPU при продуктивной нагрузке.

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

Отчеты pgpro_pwr - сформированные для продуктивной СУБД до и после обновления версии PostgreSQL .

Отчет 1 (289–295): 1 час, Postgres Pro Enterprise 17.9.2.
Отчет 2 (11989–11995): 1 час, Postgres Pro Enterprise 15.14.1.

Пропмт для генерации исходного отчета по Отчету-1

disk.yandex.ru

prompt-pgpro_pwr.289-295.txt — Яндекс Диск

Пропмт для генерации исходного отчета по Отчету-2

disk.yandex.ru

prompt-pgpro_pwr.11989_11995.txt — Яндекс Диск

Доменная инструкция pgpro_pwr

disk.yandex.ru

_instruction.txt — Яндекс Диск

Термины «эпистемический протокол» и «доменная методология» относятся к разным уровням организации познавательных процессов.

«Эпистемический протокол» и «Доменная методология»

Postgres DBA2 апреля

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

Philosophical_instruction_BETA_v5.1.md

github.com

Шаг-1: Формирование исходных отчетов с использованием доменной инструкции pg_expecto

Загрузка инструкции

Формирование отчета по pgpro_pwr.289-295.clear.html

Исходный отчет сформированный по отчету pgpro_pwr "pgpro_pwr.289-295.clear.html" с использованием доменной инструкции pg_expecto

disk.yandex.ru

Яндекс

Формирование отчета по pgpro_pwr_11989_11995.clear.html

Исходный отчет сформированный по отчету pgpro_pwr "pgpro_pwr_11989_11995.clear.html" с использованием доменной инструкции pg_expecto

disk.yandex.ru

pgpro_pwr.11989_11995.txt — Яндекс Диск

Шаг-2: Формирование аналитического сравнительного отчета

Загрузить инструкцию

Формирование аналитического отчета

От разностного отчёта — к инженерному выводу

Часть-1: Сравнительный анализ отчетов pgpro_pwr (периоды 289–295 и 11989–11995)

1.1 Анализ различий метрик СУБД

Периоды наблюдения

Отчет 1 (289–295): 1 час, 2026-04-15, Postgres Pro Enterprise 17.9.2.

Отчет 2 (11989–11995): 1 час, 2026-04-09, Postgres Pro Enterprise 15.14.1.

Уровень-1:Подтверждено данными. Сравнение проводится между разными версиями СУБД. Это ограничивает прямую сопоставимость некоторых метрик, однако характер нагрузки и проблемные паттерны схожи.

Общие характеристики нагрузки

Общее количество запросов:

Отчет 1: ~40.4 млн.
Отчет 2: ~33.7 млн.
Различие: +20% в отчете 1.

Суммарное время выполнения запросов:

Отчет 1: ~13462 сек.
Отчет 2: ~5094 сек.
Различие: в 2.6 раза выше в отчете 1.

Общий размер кластера / DB-1:

Отчет 1: 3286 GB / 2266 GB.
Отчет 2: 3581 GB / 2433 GB.
Различие: отчет 2 немного крупнее.

Пиковое число сессий:

Отчет 1: 1317 (из них 1096 в DB-1).
Отчет 2: нет данных; numbackends для DB-1 = 435.

Общее время I/O (DataFileRead):

Отчет 1: 3788 сек (7.1% от времени выполнения).
Отчет 2: 649.1 сек (12.7% от времени выполнения).
Различие: в отчете 1 больше абсолютное время I/O, но доля меньше.

Временные файлы:

Отчет 1: 197 файлов, 16 GB.
Отчет 2: 221 736 блоков (~1.7 GB) только от одного запроса; общий объем не указан.
Различие: отчет 1 показывает больший общий объем temp.

Генерация WAL:

Отчет 1: ~806 MB только от одного запроса.
Отчет 2: ~16 GB всего, из них 10 GB от одного INSERT.
Различие: отчет 2 генерирует существенно больше WAL.

Уровень-1:Подтверждено данными. Отчет 1 демонстрирует значительно более высокое суммарное время выполнения запросов при сопоставимом количестве запросов. Это указывает либо на более тяжелые запросы, либо на более высокую конкуренцию за ресурсы (CPU, I/O). В отчете 2 нагрузка по времени выполнения распределена более равномерно, но абсолютные значения времени выполнения ниже.

Уровень-2:Вероятно, но требует проверки. Разница в общем времени выполнения может быть связана с различиями в аппаратном обеспечении серверов (local vs old_local), а также с версией Postgres Pro (17.9.2 vs 15.14.1). Без метрик ОС (CPU, память, диск) подтвердить это невозможно.

Распределение нагрузки по базам данных

Отчет 1: DB-1 потребляет 99.5% запросов и 93.6% времени выполнения.
Отчет 2: DB-1 потребляет 94.91% времени выполнения; остальное в основном DB-7 (4.30%).

Уровень-1:Подтверждено данными. В обоих случаях доминирует одна база данных DB-1, что типично для многих инсталляций.

Использование CPU

Отчет 1: общее процессорное время (user+system) ≈ 31134 сек, что соответствует средней утилизации ~8.6 ядер.
Отчет 2: суммарное CPU-время по всем запросам ≈ 5550 сек (расчет по сумме CPU времени проблемных запросов плюс остальные), что существенно ниже.

Уровень-1:Подтверждено данными. Нагрузка на CPU в отчете 1 в несколько раз выше, что коррелирует с большим временем выполнения.

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

shared_buffers:

Отчет 1: 55 GB.
Отчет 2: 55 GB.
Комментарий: одинаково.

effective_cache_size:

Отчет 1: 165 GB.
Отчет 2: 165 GB.
Комментарий: одинаково.

work_mem:

Отчет 1: 64 MB.
Отчет 2: 32 MB.
Комментарий: в отчете 1 вдвое больше.

maintenance_work_mem:

Отчет 1: 256 MB.
Отчет 2: 256 MB.
Комментарий: одинаково.

autovacuum_work_mem:

Отчет 1: 256 MB.
Отчет 2: не указан (вероятно, по умолчанию -1).

max_connections:

Отчет 1: 5000.
Отчет 2: не указано в отчете 2 (вероятно, стандартное 100).
Комментарий: существенное различие.

random_page_cost:

Отчет 1: 1.1.
Отчет 2: 1.1.
Комментарий: оба оптимизированы под SSD.

checkpoint_timeout:

Отчет 1: 900s.
Отчет 2: 900s.
Комментарий: одинаково.

max_wal_size:

Отчет 1: 8192 MB.
Отчет 2: 8192 MB.
Комментарий: одинаково.

wal_buffers:

Отчет 1: 64 MB.
Отчет 2: не указано (вероятно, -1).

max_parallel_workers:

Отчет 1: не указано.
Отчет 2: 60.

max_parallel_workers_per_gather:

Отчет 1: не указано.
Отчет 2: 0.
Комментарий: в отчете 1 значение не указано, но по отсутствию параллельных планов в списке запросов предположительно тоже 0 или низкое.

autovacuum_max_workers:

Отчет 1: 30.
Отчет 2: 30.
Комментарий: одинаково.

autovacuum_naptime:

Отчет 1: 20s.
Отчет 2: 20s.
Комментарий: одинаково.
log2_num_lock_partitions:
Отчет 1: не указано.
Отчет 2: 8.

temp_file_limit:

Отчет 1: -1.
Отчет 2: не указано.

Уровень-1:Подтверждено данными. Ключевое различие: work_mem = 64 MB в отчете 1 против 32 MB в отчете 2. Несмотря на более высокое значение в отчете 1, объем временных файлов там выше (16 GB против ~1.7 GB от одного запроса в отчете 2), что может объясняться значительно более высокой частотой запросов, требующих temp (см. раздел запросов).

Уровень-2:Вероятно, но требует проверки. max_connections = 5000 в отчете 1 является экстремально высоким и может создавать избыточные накладные расходы на управление соединениями и блокировками, особенно при пиковой нагрузке в 1317 сессий. В отчете 2 этот параметр не указан, но количество активных сессий в DB-1 составляет 435, что значительно меньше.

Уровень-3:Предположение. В отчете 1 параллелизм, скорее всего, также отключен или ограничен, так как в списке проблемных запросов нет упоминаний о параллельных планах. Без точных данных max_parallel_workers_per_gather невозможно утверждать.

1.3 Анализ различий проблемных SQL запросов

Общие паттерны

В обоих отчетах выделяются одинаковые категории проблемных запросов:

Частые вызовы SELECT FASTTRUNCATE (очистка временных таблиц).
Операции с таблицей BinaryData (чтение и вставка BLOB-объектов).
Запросы, активно использующие временные файлы.

Однако количественные характеристики различаются.

Запросы FASTTRUNCATE

Query ID:

Отчет 1: c8d5307d3be5cf9b.
Отчет 2: 282815e9f8a309e1.

Количество вызовов:

Отчет 1: 500 930.
Отчет 2: 1 200 000 (в 2.4 раза больше).

Общее время выполнения:

Отчет 1: 2731.7 сек.
Отчет 2: 1178 сек.

Среднее время:

Отчет 1: 5.45 мс.
Отчет 2: ~0.98 мс.

CPU время:

Отчет 1: 1135.5 + 660.8 = 1796.3 сек (сумма по двум планам).
Отчет 2: 1155.8 сек.

Доля от общего CPU:

Отчет 1: 37.7%.
Отчет 2: 20.8%.

Временные файлы:

Отчет 1: не указано в контексте этого запроса.
Отчет 2: 221 736 блоков (~1.7 GB).

Генерация WAL:

Отчет 1: 806 MB.
Отчет 2: нет данных.

Уровень-1:Подтверждено данными. В отчете 2 запрос FASTTRUNCATE вызывается в 2.4 раза чаще (1.2 млн против 0.5 млн), но при этом его суммарное время выполнения и CPU-затраты ниже, чем в отчете 1. Это объясняется тем, что в отчете 1 среднее время выполнения одного вызова значительно выше (5.45 мс против 0.98 мс). Возможные причины более медленного выполнения в отчете 1:

Более высокая конкуренция за CPU из-за общего количества сессий (1317 против 435).
Различия в версиях СУБД (17.9.2 vs 15.14.1) или настройках.
Более крупные временные таблицы, требующие больше работы при очистке.

Уровень-2:Вероятно, но требует проверки. Разница в среднем времени выполнения может быть связана с тем, что в отчете 1 временные таблицы создаются с большим количеством данных, либо сервер local испытывает более высокую нагрузку на CPU, что замедляет выполнение даже легковесных операций.

Запросы к таблице BinaryData

Чтение:

Отчет 1: Query ID 5361d28fd4412420; 488 421 вызовов; суммарное время 474 сек; прочитано ~5.3 GB; cache hit 91%.
Отчет 2: Query ID cd845f144c03c3a3; 431 638 вызовов; прочитано 4.57 GB; cache hit 95%.

Вставка:

Отчет 1: не выделена как критичная по времени, но генерирует WAL (806 MB от FASTTRUNCATE).
Отчет 2: Query ID 5d1540aec66be28e; 79 980 вызовов; генерирует 10 GB WAL; грязнит 1.3 млн буферов.

Уровень-1:Подтверждено данными. В отчете 2 явно выделен INSERT в BinaryData как крупный генератор WAL (10 GB), тогда как в отчете 1 основной вклад в WAL дают операции FASTTRUNCATE. Чтение из BinaryData в обоих случаях происходит очень часто и с невысоким (хотя и приемлемым) процентом попадания в кэш.

Уровень-2:Вероятно, но требует проверки. Низкий cache hit ratio (91% и 95%) при таких объемах данных может указывать на то, что активно используемые BLOB-объекты не помещаются в shared_buffers или кэш ОС. В отчете 1 это приводит к большему времени I/O (5.3 GB прочитано за 62.4 сек I/O времени).

Запросы с интенсивным использованием временных файлов

Отчет 1:

12cb2ccff375e7e (INSERT, 36 вызовов, 82 сек, ~150k блоков temp).
1fe766d42289380e (INSERT, 10 вызовов, 24 сек, ~42k блоков temp).

Отчет 2:

2c6d4359bcc70e78 (INSERT INTO pg_temp, 47 вызовов, 112 сек, 193 790 блоков temp).

Уровень-1:Подтверждено данными. В обоих отчетах присутствуют единичные запросы, создающие большой объем временных файлов, что указывает на нехватку work_mem для конкретных операций (например, сортировки или хеш-агрегации). В отчете 2 один такой запрос генерирует почти 200k блоков temp, что сопоставимо с суммарным объемом от нескольких запросов в отчете 1.

Тяжелые аналитические запросы

Отчет 1:

2bcd5d98e843d7a9 (1 вызов, 29 сек, прочитано ~900 MB).
e36e4feec7c34b3 (1 вызов, 29 сек, прочитано ~3.2 GB с Seq Scan).

Отчет 2: явно не выделены, но есть запросы с высоким временем выполнения (например, 2c6d4359bcc70e78).

Уровень-1:Подтверждено данными. В отчете 1 присутствуют единичные тяжелые запросы, сканирующие большие таблицы, что создает кратковременные всплески I/O и CPU. В отчете 2 подобные всплески не столь выражены.

1.4 Ключевые проблемы СУБД и инфраструктуры

Общие для обоих отчетов (Уровень-1 и Уровень-2)

Аномально высокая частота вызовов SELECT FASTTRUNCATE — указывает на неоптимальную работу приложения с временными таблицами. (Уровень-1)
Недостаточный work_mem для отдельных операций, приводящий к интенсивному использованию временных файлов. (Уровень-1)
Операции с таблицей BinaryData создают высокую нагрузку на чтение и/или запись WAL. (Уровень-1)
Отключенный или неэффективно используемый параллелизм — в отчете 2 явно max_parallel_workers_per_gather = 0, в отчете 1 предположительно также. (Уровень-1 для отчета 2, Уровень-2 для отчета 1)

Специфичные для отчета 1 (289–295)

Экстремально высокое значение max_connections = 5000 при пиковом количестве сессий 1317 создает избыточные накладные расходы. (Уровень-2)
Очень высокое общее время выполнения запросов (13462 сек) при сопоставимом количестве запросов, что может свидетельствовать о перегрузке CPU или конкуренции за ресурсы. (Уровень-1)
Значительное время ожидания ClientRead (91.5%) — возможно, приложение держит соединения открытыми без активности. (Уровень-2)

Специфичные для отчета 2 (11989–11995)

Большой объем генерации WAL (16 GB) в основном за счет вставок в BinaryData. (Уровень-1)
Более низкая утилизация CPU по сравнению с отчетом 1 (суммарное CPU-время около 5550 сек против 31134 сек). (Уровень-1)
Отсутствие данных о пиковых сессиях и max_connections не позволяет оценить потенциальную проблему с переподпиской. (Уровень-4)

Проблемы инфраструктуры (общие для обоих отчетов)

Уровень-4:Невозможно оценить. В обоих отчетах отсутствуют системные метрики (CPU, память, диск, сеть) и логи PostgreSQL. Невозможно проверить признаки:

Silent error swallowing (нет логов).
Resource leaks (нет трендов соединений, temp файлов).
Race conditions (нет vmstat).
Copy-paste конфигурации (часть параметров проверена, но без данных ОС нельзя оценить адекватность effective_cache_size, random_page_cost и др.)

1.5 Рекомендации на основании сравнительного анализа

Рекомендации разделены на применимые к обоим серверам и специфичные для каждого.

Общие рекомендации (Уровень-2, требуют проверки в тестовой среде)

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

Проанализировать код, ответственный за создание и очистку временных таблиц.

Рассмотреть возможность использования ON COMMIT DELETE ROWS / ON COMMIT DROP вместо явного TRUNCATE.

Если временные таблицы используются для промежуточных результатов, оценить замену на CTE.

Увеличение work_mem для проблемных запросов.

Начать с увеличения до 128 MB (для отчета 1) и до 64–128 MB (для отчета 2).

Контролировать общее потребление памяти с учетом количества активных сессий.

Включение параллелизма для подходящих запросов.

Установить max_parallel_workers_per_gather = 2 или 4 (если не установлено).

Проверить влияние на время выполнения сканирующих и агрегирующих запросов.

Анализ и оптимизация запросов к таблице BinaryData.

Получить планы выполнения (EXPLAIN (ANALYZE, BUFFERS)) для запросов чтения и вставки.

Проверить эффективность индексов. Рассмотреть возможность партиционирования таблицы по времени или другому ключу.

Оценить целесообразность выноса BLOB-объектов в отдельное файловое хранилище (особенно для отчета 2 с высоким WAL).

Специфичные рекомендации для отчета 1 (сервер local, PG 17)

Пересмотреть значение max_connections. (Уровень-2) При пике 1317 значение 5000 избыточно. Рекомендуется снизить до, например, 1500–2000, чтобы уменьшить накладные расходы на управление соединениями.
Исследовать причину высокого времени ClientRead. (Уровень-2) Проверить сетевые задержки между сервером приложений и БД, а также логику пула соединений в приложении (нет ли длительных простоев с открытой транзакцией).
Провести профилирование CPU. (Уровень-3) Высокое суммарное CPU-время требует анализа на уровне ОС (perf top, pg_stat_statements с детализацией по запросам) для выявления точных потребителей.

Специфичные рекомендации для отчета 2 (сервер old_local, PG 15)

Оптимизировать INSERT в BinaryData для снижения генерации WAL. (Уровень-2)
Рассмотреть возможность использования ALTER TABLE BinaryData SET (autovacuum_enabled = off) с последующей ручной очисткой, если таблица преимущественно растет и редко обновляется/удаляется.
Проверить, не используется ли избыточное количество индексов на таблице.
При возможности перейти на хранение больших BLOB вне БД.
Увеличить work_mem как минимум до 64 MB, поскольку текущие 32 MB явно недостаточны для наблюдаемой нагрузки с временными файлами. (Уровень-2)

Необходимые дополнительные данные для углубленного анализа (Уровень-3 и Уровень-4)

Для обоих серверов требуется собрать:

Системные метрики за аналогичный период: sar -u, iostat -x, vmstat, free -h.
Логи PostgreSQL с акцентом на предупреждения (WARNING), особенно о частых контрольных точках, длительных транзакциях, проблемах autovacuum.
Статистику по таблицам и индексам (pg_stat_user_tables, pg_stat_user_indexes) для оценки эффективности autovacuum и использования индексов.
Планы выполнения для ключевых проблемных запросов (FASTTRUNCATE, BinaryData, запросы с temp).
Тренды количества соединений, временных файлов, использования памяти процессами PostgreSQL в долгосрочной перспективе (сутки/неделя) для выявления утечек.

1.6 Заключение и необходимая информация для углубленного анализа

Уровень-1:Подтверждено данными. Оба сервера демонстрируют схожие паттерны проблем производительности, связанные с неоптимальным использованием временных таблиц и операциями с большими бинарными объектами. Однако отчет 1 (более новая версия PG, сервер local) характеризуется значительно более высоким суммарным временем выполнения и большей нагрузкой на CPU, что может объясняться как различиями в аппаратном обеспечении, так и более интенсивной конкуренцией за ресурсы из-за высокого числа одновременных сессий.

Уровень-2:Вероятно, но требует проверки. Различия в значениях work_mem (64 MB против 32 MB) и max_connections (5000 против неизвестного) могут влиять на наблюдаемую производительность. Отключенный параллелизм в отчете 2 (и, вероятно, в отчете 1) ограничивает использование многоядерных CPU.

Уровень-3:Предположение. Для точного определения узких мест и выработки целевых рекомендаций необходимо провести дополнительный сбор метрик, как указано выше. Без этих данных любые изменения конфигурации должны тестироваться в изолированной среде с имитацией реальной нагрузки.

Уровень-4:Невозможно оценить. Влияние инфраструктуры (дисковая подсистема, память, сеть) на наблюдаемые проблемы остается неизвестным. Настоятельно рекомендуется включить сбор системных метрик и логов для будущих периодов мониторинга.

1.7 Промежуточный итог

Проведённый сравнительный анализ двух часовых нагрузочных профилей PostgreSQL, зафиксированных средствами pgpro_pwr до (версия 15.14.1) и после (версия 17.9.2) обновления СУБД, выявил статистически значимые различия в ключевых метриках производительности при сохранении общей структуры прикладной нагрузки. Несмотря на увеличение общего количества запросов на 20% в отчёте 2 (версия 17), суммарное время выполнения запросов возросло в 2,6 раза, а процессорное время — более чем в 5 раз, что указывает на кардинальное изменение эффективности выполнения операций, не объяснимое исключительно ростом числа вызовов. Конфигурационные различия (work_mem 64 МБ против 32 МБ, max_connections 5000 против неуказанного, отключённый параллелизм в обеих версиях) не дают однозначного объяснения наблюдаемому росту нагрузки на CPU. При этом характер проблемных запросов (FASTTRUNCATE, чтение/вставка BLOB-объектов, временные файлы) остался неизменным, однако их средняя стоимость в терминах процессорного времени значительно выросла в версии 17, что требует углублённого исследования на уровне планов выполнения и системных метрик.

Часть-2: Сравнение аналитического отчета, сформированного по инструкции, с базовым разностным отчетом pgpro_pwr

Ключевые отличия аналитического отчета

Стандартный разностный отчет pgpro_pwr (далее — diff-отчет) предоставляет числовое сравнение двух снимков метрик (значения, дельты, процентные изменения). Он является инструментом визуализации сырых данных, но не выполняет экспертной интерпретации. Аналитический отчет, подготовленный согласно предоставленным инструкциям, отличается по следующим критериям.

2.1. Эпистемическая маркировка выводов (Уровни достоверности)

Отсутствует в diff-отчете. Diff-отчет не разделяет факты, предположения и гипотезы. Все представленные числа имеют одинаковый вес, что может вводить в заблуждение при принятии решений.