Дописал приложение. Теперь можно поймать разные планы для запроса. Пример:
Что для этого нужно, написано здесь: How to catch execution plans for queries.
Вашу статью про auto_explain прочитал — инструмент хороший, но я не вижу приличного способа как-то парсить в десктопном приложении текстовый лог, расположенный на сервере БД.
Тут надо определиться, что мы считаем «разными» планами.
Если мы говорим про такие поля, как COST и ROWS, то они конечно же будут отличаться, т.к. при EXPLAIN они формируются на основе статистики и некой абстрактной стоимости операций чтения и т.п.
А если мы говорим про план, как про непосредственно метод доступа к данным, то тут надо понимать, что если между моментом фактического выполнения запроса и моментом выполнения EXPLAIN случилось нечто, что влияет на план (например, удаление индекса), то результаты тоже могут не совпасть.
Однако, учитывая, что мы посылаем команду EXPLAIN в ту же секунду, что и сам запрос, то вероятность описанного выше события крайне низка.
Полагаю, что у вас не PostgreSQL 10.
В 9-ой версии такого поля действительно нет. Я мог бы без него и обойтись в запросе, но там и ожиданий очень мало — вряд ли будет интересно наблюдать. Если я для вас скомпилирую версию под 9-ку — выложите мне в ответ её скриншоты под нагрузкой?
Если наша цель — не допустить перегревания процессора, то в случае выхода из строя кондиционера нужно, как я понимаю, не пороги поднимать, а чинить кондиционер, либо выключать компьютеры.
Про макросы согласен. Но проблема остается — я к тому, что очень уж трудоемка следить за парком машин от 1000шт.
В идеале нужно, чтобы программа агент по модели CPU сама решала, перегрелся он уже или нет, и на сервер мониторинга сообщала не температуру, а статус — OK, WARN, CRIT…
А разве у разных моделей CPU не разные рабочие диапазоны температур? Не получится наложить один шаблон на все наблюдаемые машины с триггерами на превышение нормальных значений. Придется готовить разные шаблоны для каждой модели CPU.
Рядом со мной в одном кабинете уже 5 лет работает программист 1с, в/о, 36 лет, активный пользователь интернета. Как оказалось, он поддерживает текущую политику по ограничению распространения информации, аргументируя тем, что все, кто критикует власть — есть пятая колонна. Я, когда наткнулся на это его мнение (непробиваемое), испытал когнитивный диссонанс. Оказалось, что такие люди есть в непосредственной близости.
Мы не просто живём с ним в одной стране. Он (в составе некой группы лиц) нашей страной руководит. Кто-то может возразить, мол, мы его не выбирали. Однако при достаточном желании руководителя поменять можно всегда. А значит, мы соглашаемся с его текущей политикой и в ответе за неё.
Мария, успехов в этом непростом деле! :)
Что для этого нужно, написано здесь: How to catch execution plans for queries.
Вашу статью про auto_explain прочитал — инструмент хороший, но я не вижу приличного способа как-то парсить в десктопном приложении текстовый лог, расположенный на сервере БД.
github.com/dbacvetkov/PASH-Viewer/releases
github.com/dbacvetkov/PASH-Viewer/wiki/How-to-create-pg_stat_activity-historical-table
Если мы говорим про такие поля, как COST и ROWS, то они конечно же будут отличаться, т.к. при EXPLAIN они формируются на основе статистики и некой абстрактной стоимости операций чтения и т.п.
А если мы говорим про план, как про непосредственно метод доступа к данным, то тут надо понимать, что если между моментом фактического выполнения запроса и моментом выполнения EXPLAIN случилось нечто, что влияет на план (например, удаление индекса), то результаты тоже могут не совпасть.
Однако, учитывая, что мы посылаем команду EXPLAIN в ту же секунду, что и сам запрос, то вероятность описанного выше события крайне низка.
В 9-ой версии такого поля действительно нет. Я мог бы без него и обойтись в запросе, но там и ожиданий очень мало — вряд ли будет интересно наблюдать. Если я для вас скомпилирую версию под 9-ку — выложите мне в ответ её скриншоты под нагрузкой?
Просто разобрался не сразу. Использую первый раз, поэтому не факт, что всё сделал правильно.
В идеале нужно, чтобы программа агент по модели CPU сама решала, перегрелся он уже или нет, и на сервер мониторинга сообщала не температуру, а статус — OK, WARN, CRIT…