Запилил мануал по pg АВР 4.1.3.

Ну как мануал. Почти книжка, брошюра. Правда коллега шутит что это Курсовая. Ну а чо. Если есть целые две математические формулы

Накрутили в АВР уже конечно мощно. Появилось понятие администрирования АВР. Авто кастомизации, модульность.

Оказывается купить вы его уже можете. Но он идёт только с поддержкой. Стоит правда хз сколько.

С реплики нет снимков. Но в нашей целевой архитектуре это и не нужно, т.к. haproxy перенаправляет запросы на лидер кластера. То есть выполнение запросов с синхронной реплики не приветствуется, т.к. какие то тяжёлые запросы на реплике могут аффектить лидер, вследствии чего на нем возникать ожидания SyncRepl.

Отличия от pg_profile:
1. Снимки делаются без сброса статистики pg_stat_statements. То есть математика получения данных в интервале времени не интегральная, а дифференциальная.
2. Сделан акцент на получение общих данных инстанса целиком без деталировки по БД отдельно. Нет например статисти по таблицам и индексам. Но при этом больше системных данных. Реализован полноценный Active session history, как связка pg_stat_activity + top + io. То есть в pg_stat_activity добавлена информация по утилизации ЦПУ, памяти и вводу выводу конкретным процессом/сессией.
3. Есть модульность. Разные метрики собираются с разной периодичности. И сборку отдельных метрик можно отключать.
4. Есть автокастомизации. То есть на очень высоких нагрузках и объемах статистических данных модули поднастратваются по параметрам чтобы обеспечить живучесть.
5. В отличие от pg_profile, в pg_awr снимки делаются быстрее. Типовое время на нагруженной системе не более 0.3-0.4 сек. Против 6 сек на pg_profile. То есть при необходимости интервал снимков может быть и Оракловым для ASH - 1 сек.

Исправил кое какие неточности в документации. Релиза версии 4.1.3 пока не было, ожидаем в конце недели.

(Но Базя уменьшил лимит вложений ) Если кому нужно - пишите в ЛС

В pg awr ещё такой двойной DB Time. В Оракле только по ASH.DB Time ASH – берется из представления pg_stat_activity с дискретизацией сбора снимков. Чем
меньше интервал сбора снимков, тем точнее это значение. Она учитывает откаченные и
незавершенные сессии.

DB Time commited - берется из представления pg_stat_statements, и не учитывает откаченные или
незавершенные сессии. Дискретизация сбора метрик здесь значения не имеет в силу специфики
работы pg_stat-statements.

DB Time по метрике ASH и Commited может быть больше интервала между снимками отчета по
поятным причинам, не IDLE сессий может быть много, и это время суммируется. То есть, например,
если в интервале отчетов 1 мин было 10 активных сессий, но которые продолжали работу и
выполняли 1 запрос в каждой из них, то DB Time ASH будет 10 мин. Если запросы при этом не
завершились или были откачены, то DB Time commited будет равно 0.

В целом соотношение между DB Time ASH и DB Time commited характеризует профиль нагрузки.
При высоком значении DB Time ASH и меньшем DB Time commited – соответствует OLAP нагрузке.
Если наоборот, то OLTP.

DB Time полезен для того чтобы сравнить профили нагрузки системы в разных интервалах времени и для анализа отклонений. Например, когда система декларирована
архитектурой как OLTP, но ведет себя как OLAP – это может говорить о наличии проблем, длинных
запросов, и может потребовать их оптимизации.