По сути ничем. Только архитектурой. О ней и была речь. Почему? Хорошие практики работы с секционированными таблицами всем интересны.

Письмо пришло. )

Приехал на WD 2025 Summer. Попросили рассказать о PG AWR. Вобщем будет доклад минут на 30. Будут слушать серьезные люди.

Начало в 11:00. Но приехал пораньше и.к. нужно отладить техническую часть.

В сентябре вышел pg awr 4.1.3. Финальная документация во вложении.

Выходим на уровень ЦБ. )

Скоро ожидается выход новой моей статьи на Хабр и выступление на ближайшем PgConf 2026.

Тема весьма интересная, это фактическое определение профилей нагрузки БД. У вас есть шанс назвать формулу своим именем и прославится на весь Мир на уровне Кодда или Ларри Элисона. Мы пока сами на докопали, но куда копать я расскажу на конференции.

Эксклюзив. Шаблон презентации, о чем речь. Это ещё никто не видел.

За конференции бабки не дают. Паник пусть сам занимается своей матерью. Чай не инвалид, взрослый мужик. С Рыбой сношается, на нее бабки тратит.

Запилил новую статью на Хабре. На этот раз снова про мониторинг. Об определении фактического профиля нагрузки БД.

В принципе это Data Science. Чистая статистика.

https://habr.com/ru/companies/vtb/articles/1011188/

Реакция.

Оценка статьи со стороны ИИ.

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

Вот ключевые аспекты, которые можно применить на практике прямо сейчас:

1. Чёткий метод диагностики «настроение БД»

Автор предлагает простой, но мощный приём: смотреть не на каждый график по отдельности, а на комбинацию state + wait_event + wait_event_type из pg_stat_activity.

· Что даёт на практике: Быстро отличать нормальную работу CPU (active/NULL) от проблем ввода-вывода (active/DataFileRead/IO), блокировок (active/relation/Lock) или «зависших» транзакций приложения (idle in transaction/ClientRead/Client).
· Как применить: Вы можете прямо сейчас написать скрипт мониторинга (Zabbix, Prometheus), который строит график с этими комбинациями — это заменит десятки других графиков для быстрой оценки ситуации.

2. Объективная формула профиля нагрузки (OLTP ↔ OLAP)

Главное новшество — метрика Profile ratio на основе сравнения DB Time (ASH) и DB Time (committed).

· В чём суть: Она показывает, каких запросов больше в интервале — коротких транзакционных (OLTP) или длинных аналитических (OLAP).
· Практические действия: Если для системы, задуманной как OLTP, коэффициент вдруг стал выше 500-700 (особенно при интервале сбора 1-5 минут), вы получаете ранний триггер. Это повод проверить:
· Не появились ли неоптимальные отчёты на продуктивной БД.
· Хватает ли shared_buffers (иначе много DataFileRead).
· Не пора ли менять архитектуру (индексы, секционирование).

3. Отдельный алгоритм для Archive Database (критично для больших инфраструктур)

Автор детально разбирает риски, когда архивную БД («только чтение, редкие запросы») начинают использовать как обычную продуктивную.

· Главная опасность: У архивных БД обычно минимум индексов, слабые ресурсы (CPU/RAM) и очень редкие бекапы (раз в квартал/год). Внезапная OLTP-нагрузка разрушит производительность, а случайное удаление данных будет невосстановимо.
· Практический вывод: Внедрите мониторинг этой самой метрики Profile ratio специально для архивных систем. Как только она отклоняется от «около 0» (долгие запросы) или «около 1000» (пакетная загрузка) — срочно проверять, не начали ли её использовать как «скрытый продуктив».

4. Готовые рекомендации по интервалу сбора

Автор приводит эмпирические данные, что оптимальный интервал сбора метрик ∆t для Profile ratio — от 2 до 7 минут (удобнее 5 минут). Это избавит вас от ошибок (слишком малый интервал сольёт все профили в OLAP, слишком большой — сделает их неразличимыми).

Главное ограничение для практики

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

Краткий вердикт: Это не просто теоретическая статья, а готовый инструментарий для инженеров. Вы можете взять предложенные SQL-запросы, формулы и пороговые значения и внедрить их в свою систему мониторинга PostgreSQL уже на следующей неделе.