Комментарии 9
Вас не смущает тот факт что у вас запросы могут выполняться более 1 минуты и вы можете ждать до 1 часа? Мне кажется у вас серьезные проблемы с оптимизацией. Напишите лучше как вы оптимизировали и меняли запросы и базу данных чтобы уменьшить максимальное время запроса хотя бы до 5-10 секунд (Это на случай если у вас там огромные базы данных и очень сложные запросы).
Меня давно уже ничего не смущает. Насмотрелся на великое множество разных запросов и решений современных разработчиков . Удивить сложно.
Я, как DBA никак не могу оптимизировать и менять запросы. Во-первых это ORM(будь он проклят) , во-вторых по современным трендам - к DBA обращаются уже когда запустили в продуктиве-"ой у нас система тормозит". На этапе разработки, мы не участвуем. Для современных разрабов База данных это ящик для хранения данных , как СУБД работает и какими обладает возможностями они не знают или знают на уровне Джуна DBA.
Золотые слова. Абстракция от способа работы черного ящика выходит тем дороже, чем больше в этом ящике данных, и чем чаще в него заглядывает вышележащий слой. Я своих дрючу:
1. К БД ходим, как оптовые покупатели - один раз со списком товаров, грузим телегу и вывозим (включая и походы за изменениями)
2. все, что часто запрашивается ИЛИ связано с большим количеством данных - должно выполняться за логарифмическое время.
Крутитесь, как хотите - но если этих условий в архитектуре солюшена нет - в реальных условиях долго он не проработает. Обычно эти слова эквивалентны таким - выбросите ORM и разговаривайте с БД не на четырех словах из вашего лексикона (C, R, U, D) - а используя всю мощь языка, за поддержку которого ваш клиент заплатил разработчику движка СУБД.
Меня начинают волновать запросы, выполняющиеся больше 100 миллисекунд. Минуты, часы... Я б умер от инфаркта
Не силён в данной теме. Но есть же такой инструмент как pgbadger, позволяющий на основе логов получить информацию о времени выполнения запросов
Построение гистограммы максимального и среднего времени выполнения запросов для PostgreSQL