Комментарии 5
Сложно-то как. А почему не посмотреть количество прочитанных буфером простым explain (analyze, buffers)?
(К слову, для ожиданий есть pg_wait_sampling, а для просмотра плана работающего запроса - pg_query_state).
Конечно же можно использовать explain(analyze, buffers). Но иногда хочется узнать кроме сколько еще и какие буферы прочитаны.
Также с помощью проб можно получить информацию с backend'а работающего приложения, а не из explain'а в своей сессии.
До 17-ой версии была одна функция было легче)
Иногда хочется получить трейс ожиданий, напоминающий 10046-ой оракловый трейс (возможно это моя профдеформация), и тут ничего другого, как watchpoint на my_wait_event_info я не придумал.
Спасибо за комментарий, расширения посмотрю.
Кажется все равно Вы усложнили задачу. Есть масса полезных расширений чтобы покопаться во внутренностях. Ну и если у Вас managed database к примеру, то gdb и perf тут в пролете.
Я ориентировался на конфигурацию PostgreSQL с минимумом расширений при наличии привилегированного доступ к ОС (я нахожусь на стороне провайдера DBaAS).
Расширения так или иначе влияют на производительность (и не только); для ожиданий сэмплирования может быть недостаточно.
А использование проб для PostgreSQL вполне удобно на мой взгляд.
Я хотел бы добавить, что иногда полезно устанавливать CUSTOM планы на уровне функции, т.к иногда это сильно ускоряет(в десятки раз) выполнение сложного запроса в функции.
Пример.
LANGUAGE plpgsql
STABLE STRICT
SET plan_cache_mode TO 'force_custom_plan'
AS $function$
Custom- и Generic-планы в PostgreSQL