Построение гистограммы максимального и среднего времени выполнения запросов для PostgreSQL

[Maxim_Q]

Вас не смущает тот факт что у вас запросы могут выполняться более 1 минуты и вы можете ждать до 1 часа? Мне кажется у вас серьезные проблемы с оптимизацией. Напишите лучше как вы оптимизировали и меняли запросы и базу данных чтобы уменьшить максимальное время запроса хотя бы до 5-10 секунд (Это на случай если у вас там огромные базы данных и очень сложные запросы).

[rinace]

Меня давно уже ничего не смущает. Насмотрелся на великое множество разных запросов и решений современных разработчиков . Удивить сложно.

Я, как DBA никак не могу оптимизировать и менять запросы. Во-первых это ORM(будь он проклят) , во-вторых по современным трендам - к DBA обращаются уже когда запустили в продуктиве-"ой у нас система тормозит". На этапе разработки, мы не участвуем. Для современных разрабов База данных это ящик для хранения данных , как СУБД работает и какими обладает возможностями они не знают или знают на уровне Джуна DBA.

[supersmeh]

Меня начинают волновать запросы, выполняющиеся больше 100 миллисекунд. Минуты, часы... Я б умер от инфаркта

[rinace]

Это потому, что вы не видели план выполнения запроса стоимостью триллион и вопрос разрабов и руководителя проекта - "почему приложение тормозит? У нас хороший код, мы упёрлись в СУБД".

[leotsarev]

Все эти пункты могут быть правдой. Код хороший, в СУБД уперлись.

Это просто значит, что архитектура говно.

[rinace]

Может, я конечно ошибаюсь, но если backend отправляет запрос и получает в ответ несколько сотен тысяч строк(из десятков столбцов), вряд ли это хороший код. По крайней мере, с точки зрения DBA.

[Froncast]

Не силён в данной теме. Но есть же такой инструмент как pgbadger, позволяющий на основе логов получить информацию о времени выполнения запросов

[rinace]

А попробуете представить - сколько по размеру будет лог содержащий информацию о нескольких десятках-сотнях миллионов запросов ?