Господа, может у вас будут идеи. У меня внезапно без изменения каких-либо параметров, упала скорость запроса в постгре, если в начале дня select request выполнялся за 100мс, то к концу дня этот показатель упал до 1000-1200мс, ума не приложу куда копать

можно ли сделать в таблице тип uint16 ? и uint8 ?

А какие утилиты есть смысл использовать для проверки базы данных. Я покидал эксплейны на обычные короткие запросы вроде SELECT count(*) FROM pg_class, pg_index WHERE oid = indrelid AND indisunique;, - вроде всё норм 1.1-1.3мс, запрос который летит от приложения я продублировать не могу, т.к. он через навороченную функцию отправляется, а у меня слишком слабое понимание самой постгри чтобы понять что он конкретно делает и выполнить что-то похожее. Соответственно, мб есть какие-то готовые решения, которые позволяют проверить целостность базы данных?

Как связаны timinings и "целостность базы данных"?
Какая у Вас конкретно проблема?

у меня свежие решения целиком на хранимках на plpgsql, даже однострочные селекты. Потому что так легче поддерживать и мутировать модель в целом, функции - как методы доступа к данным и способ инкапсуляции структуры данных. Работает чрезвычайно быстро, и легко вести статистику запросов. Неприятный нюанс был в том, что функции на sql неправильно строили план и тормозили, при этом запрос в чистом виде или в plpgsql работал нормально

можно ли сделать в таблице тип uint16 ? и uint8 ?

> как это лучше сделать?

Пишете процедуры, которые возвращают resultsets (лучше на SQL, чем на plpgsql, если это возможно), правильно их аннотируете (см. про volatility... и вообще, прочитайте документацию про это дело, там немного). Потом вызываете, и всё. ;)

> Не падает ли производительность от того, что написан в процедуре?

Зависит от того,  на каком PL процедура (большинство PL, кроме SQL, складывают результаты SRF во временное хранилище перед возвратом, например) / что за запрос (кеширование планов может влиять).
Также см. вот это: https://wiki.postgresql.org/wiki/Inlining_of_SQL_functions

> Кешируется ли план запроса для процедуры?

Для процедуры целиком — нет.

> Кешируется ли для sql-запроса?

Да.

> Что быстрее?

Inlined SQL function — в общем, то же самое, что и view. А так, в общем, функции чуть медленнее, чем запросы в них (чудес не бывает, да ;) ).

> Если не процедура, то что использовать для выполнения запроса?

Выше имелись в виду функции, конечно. Если не они — то parameterized SQL, тут особо вариантов нет...

https://www.youtube.com/watch?v=ZFLs7-vmbdM
а тут советуют сразу json возвращать.
По идее же должно получиться чуть больше трафика, но меньше накладных расходов на маппинг, на стороне бэкенда?

конкретная проблема в том, что запросы стали обрабатываться дольше в 10-15 раз. Своп есть, но небольшой, память на виртуалке расширили и она практически полностью cached. Как посмотреть насколько приросли таблицы за определенный промежуток времени, я честно говоря хз

Я вот что-то совсем не уверен что json пропарсить будет менее затратно. Не говоря уже про то, что собрать его тоже ресурсов стоит.

так а если он фронту нужен, а на бэке его парсить не надо, отдать как есть, и всё?

На каком-то из постгрес-вторников говорили что лучше использовать функции на sql, потому что они инлайнятся, а plpgsql намного медленнее.
Я тестил разные варианты, почти всегда выигрывает обычный запрос.
plpgsql обычно чуть быстрее sql функции по факту, но cost почему-то больше у plpgsql.
У вас есть какой-то критерий для выбора подхода? Чтобы не тестить все варианты.

https://www.youtube.com/watch?v=ZFLs7-vmbdM
а тут советуют сразу json возвращать.
По идее же должно получиться чуть больше трафика, но меньше накладных расходов на маппинг, на стороне бэкенда?