Процедуры обычно позволяют значительно увеличить производительность работы.
Обычно разработчики в борьбе за скорость движутся по траектории ORM->SQL->PLpgSQL.
Те. сначала приложение работает с базой посредством какого-то ORM, потом критичные места переписываются на прямые SQLщапросы, если же и это не помогает, то пишут серверную процедуру. С процедурами основная проблема заключается в отладке и поддержке.

На простых запросах узким местом сейчас становится кана связи между клиентов и сервером. Т.е. 100% загрузить современный мощный сервер простыми  OLTP запросами не так то просто: мы упрёмся в сетку и систем каллы, а не в производительность базы. В этом отношении - stored procedures, которые могут запустить сразу много запросов на стороне сервера - это путь преодоления этого бутылочного горлышка.

Но иногда встроенные процедуры могут и тормозить. Это связано с тем, что  все не динамические запросы и встроенных процедур препарятся. Т.е. постгрес пытается использовать для них generic plan, не зависящий от конкретных значений параметров. При сильно перекошенных данных это может привести к значительному проседанию на некоторых наборах параметров.

Обычно время выполнения запроса, показываемое explain analyze почти не отличается от времени выполнения запроса без него. gettimeofday в большинстве систем реализован  достаточно эффективно и не требует system call-а.  Так что разница не должна превышать единиц процентов. Мне казалось, что негативный эффект на скорость работы от включённого  auto_explain  скорее будет связан с значительным  увеличением объёма записи в лог файл. Но это почти  не зависит от того включён ли analyze или нет.

Хотим сделать запросы через процедуры к postgкуSQL, как это лучше сделать?
Не падает ли производительность от того, что написан в процедуре?
Кешируется ли план запроса для процедуры? Кешируется ли для sql-запроса? Что быстрее?
Если не процедура, то что использовать для выполнения запроса?

Приперекосах это может привести к шар или дед локам ) .. а не только к просиданию )
>В этом отношении - stored procedures, которые могут запустить сразу много запросов на стороне сервера - это путь преодоления этого бутылочного горлышка.
Так же если исползовать секции with в рамках хранимых процедур вы рискуете выбрать всю доступную память для коннекта и налететь на SWOP данных ... что значительно уменьшит скорость работы

простое предостережение

или я не прав ?

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

pg stat statements