PL/C - ?
хранимки на языкая "sql" и "plpgsql" хранятся в виде prepared запросов (при первом запуске на коннекте) + время на сам вызов процедуры => (хоть я и не тестил) если скорость суперкритична, то может лучше и prepared; в обычной жизни, если библиотека доступа сама не делает prepared, то зачем возиться, если есть хранимки.

авторВ догонку:
Есть ли какая-нибудь разница в скорости выполнения между созданием двух хранимых функций и одной хранимой функции, которая по разному ведет себя в зависимости от одного из параметров?
Две разных наверно будут быстрее, так как plpgsql даже проверку условий в if .. then делает через запрос (prepared). Опять-таки - тебе правда суперкритична скорость?

Прежде всего - я не мастер и моё мнение может быть ошибочным.

автор2) Скорость не критична. Но интересно знать, как лучше писать. Почему prepared запрос будет быстрее, если при каждом его вызове будет проходить построение плана выполнения?

Не будет, только один раз при создании - в том-то и весь смысл prepared. Только между коннектами он не сохраняется, поэтому запрос, выполняемый один раз за коннект нет смысла prepare-ить.
sql и plpgsql используют prepared внутри - и соответственно планы строятся при первом запуске на данном коннекте.

При этом бывают интересные эфекты:
- есть запрос, который, в зависимости от параметра, выбирает 100 строк или 25% строк от большой таблицы.
- не препаред запрос в первом случае возьмет индексы, во втором - скан по таблице.
- prepared - то что было при первом запуске:
если при первом запуске выбирали 100 строк, то запомнился план с индексами, попытка второго запроса по этому плану (возвращающего 25%) будет в разы ( 2 ~ бесконечность) дольше.
если выполняли со вторым параметром, то попытка с первым также будет использовать скан по таблице => займет ровно столько же времени (не считая формирования ответа)
В этом случае запрос обрамляется в EXECUTE - и план не сохраняется :-) .

Более того - таже беда и у (вы не поверите) MS SQL Server, только хуже - там планы запросов для сохраненок оседают до перекомпиляции процедуры (процесс то один, все потоками, а у PostgreSQL - один коннект - один процесс).

Мое мнение:
- если это джоб, который выполняется раз за коннект - по фигу. Я выбираю либо
вообще не делать prepare ни в каком виде (все на клиенте), либо процедура (чтоб на серваке лежало).
- если 100 раз за коннект _однообразная_ работа как можно скорее и скорость выполнения каждого раза мала (=> сопоставима с распарсовкой запроса), то либо процедура(чаще), либо prepared (если библиотека может сама сделать - здесь чистая теория, я использую python, и такого не видел, может плохо смотрел), либо все вместе.
- если >1 раза с ситуацией выше (от параметра сильно зависит) - то на стороне клиента НЕ PREPARE!!!! или EXECUTE в процедуре.

Кроме того, если у тебя секьюрити через хранимки, то какой тогда prepare ? только для вызова самой процедуры.....

PS.
Блин, вот я разумничался. Сам дурак-дураком, а воображаю .... и русский не мешало бы подучить.