Спасибо, Simon!

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

Ну да. Я подразумевал "негативно отражается", извините.
Т.е. "не стало ли хуже на 10%? от этого patch?".

А я понял. Но эти задачи похожи. Хотя «хуже» получается чаще :)

я знаю, что distinct учитывает и null, так что если записи с null повторяются, то он считает их за дубли и исключает, однако мне это не нужно.
мне надо, чтобы distinct (или что-то похожее) исключал дубли только в том случае, если они не null, а иначе distinct к ним применяться не должен, но я не знаю как такое написать.
сейчас запрос выглядит так: https://pastebin.com/cag4UBUQ
но он неправильный, потому что те записи, у которых parent_id null, считаются за одну, хотя не должны.
дадите подсказку?

Сделайте where parent_id is not null и union (или cte) с where parent_id is null, например.

Еще можно попробовать сделать COUNT(DISTINCT parent_id) + COUNT(parent_id is null) - 1, но я не уверен, что это корректно посчитает.

Спасибо за ответы выше, наверное не совсем правильно задал ответ. Как измерить загрузку постгрес сессии. хз как на русский перевести, на английском я бы назвал эту метрику session busy ratio. Т.е. сколько процентов времени сессия работает, а сколько простаивает чтобы понять у нас есть запас или нет.

пока ничего такого нет, в 14 появится.

https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=960869da0803427d14335bba24393f414b476e2c

Спасибо! Оч интересно. А может какие extension есть которые более менее могут с этим помочь?

через dtrace пробы может можно?

Не, там такого нет, ток что посмотрел

А "системные" метрики загрузки CPU, использования RAM и дисков не подойдут?
А так это можно, наверное, примерно посчитать, если логировать все запросы (с длительностью), или попробовать сделать это на основании pg_stat_statements.

Там такой комбайн с 50 аппликейшенами и 100k xact/s хочется понять по каждому сколько ему реально соединений нужно. поэтому даже примерно не представляю как это посчитать с pg_stat_statements.

заведите мониторинг (в том числе по сессиям), убедитесь что нету явных косяков, особенно долгих транзакций и транзакций в idle in transaction состоянии.
дальше по нагрузке на CPU / диски / сеть можно судить о запасе

спасибо завел. Теперь думаю как такую метрику посчитать :)

привет всем у меня так крутиться очень долго что делать??

попробовать другой браузер

у меня тоже самое - так и не понял, как решить, по итогу просто развернул в докере)