Спасибо за наводку. Пробовал использовать pg_stat_statements, но в итоге вернулся к логам и pgbadger.
Мне в работе оказалась полезна ретроспектива: например, если 1 января вышло обновление с багом, в агрегированной статистике pg_stat_statements я увижу только "среднюю температуру" за всё время. Логи же позволяют "отмотать пленку" назад и сравнить производительность по конкретным дням или неделям. Так же парсинг логов через pgbadger можно вынести на отдельный сервер. Возможно, я просто еще не до конца раскрыл для себя потенциал pg_stat_statements, но для еженедельного аудита формат pgbadger мне показался нагляднее.
Спасибо за поправку! Ошибся в этом моменте — про кольцевой буфер и Buffer Access Strategy не знал, изучу. Мой фокус в этом кейсе был больше на методике регулярной проверки: как через pgbadger и системный анализ планов находить и устранять узкие места в СУБД
На самом деле получилось собрать рабочую техническую связку, которая стабильно (без галлюцинаций) вытаскивает атомарные данные по запросу на естественном языке. Под "готовностью к Enterprise" я, пожалуй, поспешно подразумевал лишь инфраструктурную часть: стек Java/Spring AI, работу в закрытом контуре и безопасность данных. С точки зрения бизнеса — это пока лишь умная поисковая строка. Статья — это в первую очередь история моего пути от наивного "сейчас заменю всех" до понимания, что ИИ — это просто новый, довольно капризный тип интерфейса к данным, у которого очень узкая ниша применения. Спасибо за конструктивную критику, она помогает правильно расставить акценты в итогах исследования.
Я действительно ставил перед собой дерзкую цель — проверить, сможет ли ИИ стать альтернативой написанию отчетов и в перспективе заменить часть рутинной работы программиста. Но эта идея провалилась.
В начале статьи я специально обозначил ожидания как "наивные". Целью исследования было не создать замену СКД (системе компоновки данных), а проверить: может ли ИИ вообще ориентироваться в структуре OData "с чистого листа".
То есть теперь, помимо ада зависимостей, нужно следить за адом лицензий?
Спасибо за наводку. Пробовал использовать pg_stat_statements, но в итоге вернулся к логам и pgbadger.
Мне в работе оказалась полезна ретроспектива: например, если 1 января вышло обновление с багом, в агрегированной статистике pg_stat_statements я увижу только "среднюю температуру" за всё время. Логи же позволяют "отмотать пленку" назад и сравнить производительность по конкретным дням или неделям. Так же парсинг логов через pgbadger можно вынести на отдельный сервер.
Возможно, я просто еще не до конца раскрыл для себя потенциал pg_stat_statements, но для еженедельного аудита формат pgbadger мне показался нагляднее.
Спасибо за поправку! Ошибся в этом моменте — про кольцевой буфер и Buffer Access Strategy не знал, изучу.
Мой фокус в этом кейсе был больше на методике регулярной проверки: как через pgbadger и системный анализ планов находить и устранять узкие места в СУБД
Рад, что статья нашла отклик, спасибо!
На самом деле получилось собрать рабочую техническую связку, которая стабильно (без галлюцинаций) вытаскивает атомарные данные по запросу на естественном языке.
Под "готовностью к Enterprise" я, пожалуй, поспешно подразумевал лишь инфраструктурную часть: стек Java/Spring AI, работу в закрытом контуре и безопасность данных. С точки зрения бизнеса — это пока лишь умная поисковая строка.
Статья — это в первую очередь история моего пути от наивного "сейчас заменю всех" до понимания, что ИИ — это просто новый, довольно капризный тип интерфейса к данным, у которого очень узкая ниша применения. Спасибо за конструктивную критику, она помогает правильно расставить акценты в итогах исследования.
Я действительно ставил перед собой дерзкую цель — проверить, сможет ли ИИ стать альтернативой написанию отчетов и в перспективе заменить часть рутинной работы программиста. Но эта идея провалилась.
В начале статьи я специально обозначил ожидания как "наивные". Целью исследования было не создать замену СКД (системе компоновки данных), а проверить: может ли ИИ вообще ориентироваться в структуре OData "с чистого листа".