Комментарии 6
в логе сервера
Обычно лог продуктивной СУБД это мегабайты . Как искать проблемную строку?
И самое главное .
Query Text: SELECT 1
Это ведь искусственный пример. В реальности так не бывает.
Как искать проблемный запрос ?
Мы разработали для себя и предлагаем другим вот такую штуку - можно потрогать демку.
Про ORM не согласен. Да, запросы вида SELECT id; SELECT * WHERE id IN (1,2,3) — они не самые оптимальные, но, как правило, далеко не критично влияют на производительность. При этом такое поведение ORM даёт то, что можно выбирать ID из одной базы, а данные из другой:
Иногда это сильно упрощает жизнь при разрезании монолита на несколько частей по-честному (то есть без общей базы). У меня такое было.
Это позволяет выбирать ID из одной базы, а данные из другой. Например, ID из ElasticSearch, а данные из основной базы. У меня сейчас так работает на нескольких проектах.
Кто понимает, зачем использует ORM, его сильные и слабые стороны, - молодец.
Увы, приходилось видеть генерированные запросы с тысячами ID-параметров, гуляющих в рамках одной базы между сервером и клиентом. Впрочем, и для разных баз можно обойтись без проброса через клиента - с помощью FDW, например.
ORM не согласен. Да, запросы вида
SELECT id; SELECT * WHERE id IN (1,2,3)— они не самые оптимальные, но, как правило, далеко не критично влияют на производительность
А если IN ( 1,2,3.... 1000, 1001)?
Я такие запросы и удивление разрабов - "ну почему ваш postgres так медленно работает ? " - видел.
PostgreSQL Antipatterns: валим «слона» — highload на ровном месте