严格来说，术语“存储过程”指向Postgres 11中引入的Postgres中的SQL过程。
还有一些功能，几乎可以完成，但不完全相同，而这些功能从一开始就存在。
功能与LANGUAGE sql基本上与一个函数包装纯SQL命令（以及因此原子，总是一个内运行刚批处理文件单个事务）接受参数。SQL函数中的所有语句都是立即计划的，这与在另一个语句之后执行一个语句有细微的差别，并且可能会影响获取锁的顺序。
除此之外，最成熟的语言是PL / pgSQL（LANGUAGE plpgsql）。它运行良好，并且在过去十年中的每个发行版中都得到了改进，但它最适合用作SQL命令的粘合剂。它不用于繁重的计算（SQL命令除外）。
PL / pgSQL函数执行查询，如准备好的语句。重用缓存的查询计划可以减少一些计划开销，并使它们比等效的SQL语句快一点，这可能会因情况而产生明显的影响。它也可能有类似以下相关问题的副作用：
此携带的优点和准备语句的缺点- 在手动讨论。对于具有不规则数据分布和可变参数的表的查询，当针对给定参数的优化执行计划获得的收益超过重新计划的成本时，动态SQL的性能EXECUTE可能会更好。
由于Postgres 9.2的通用执行计划仍在会话中缓存，因此请引用手册：
对于没有参数的准备好的语句，这种情况立即发生；否则，只有在五个或更多执行生成计划的估算平均成本（包括计划间接费用）比通用计划成本估算贵得多的计划之后，才会发生这种情况。
在大多数情况下，我们在不（ab）使用的情况下（最好不要花费额外的开销）两全其美EXECUTE。PostgreSQL Wiki的PostgreSQL 9.2中的新增功能中的详细信息。
Postgres 12引入了附加服务器变量plan_cache_mode来强制执行通用或自定义计划。对于特殊情况，请小心使用。
服务器端的功能可以防止应用程序与数据库服务器进行额外的往返，从而赢得巨大的成功。让服务器一次执行尽可能多的操作，仅返回定义良好的结果。
避免嵌套复杂的函数，尤其是表函数（RETURNING SETOF record或TABLE (...)）。函数是黑匣子，构成了查询计划者的优化障碍。它们是分开优化的，而不是在外部查询的上下文中进行的，这使计划变得更简单，但可能会导致计划不尽人意。而且，功能的成本和结果大小无法可靠地预测。
此规则的例外是简单的SQL函数（LANGUAGE sql），如果满足某些先决条件，则可以“内联”。在Neil Conway的这篇演讲中，了解有关查询计划器工作原理的更多信息（高级知识）。
在PostgreSQL中，函数总是自动在单个事务中运行。所有的一切都成功了，还是没有成功。如果发生异常，则所有内容都会回滚。但是有错误处理 ...
这就是为什么函数不完全是“存储过程”的原因（即使有时会误用该术语）。一些命令喜欢VACUUM，CREATE INDEX CONCURRENTLY或CREATE DATABASE不能在事务块内运行，因此它们没有在功能不允许的。（从Postgres 11开始，SQL过程中都没有。以后可能会添加。）
这些年来，我已经编写了数千个plpgsql函数。