uplpgsql：让 PL/pgSQL 跑在原生代码速度上
数据库存储过程的性能瓶颈一直是个挺尴尬的事，尤其是 PL/pgSQL 这种基于树遍历的解释执行方式，每一次循环、每一个 IF 判断都要走一遍 普通存储过程： 提升约 2-4 倍。
重度数值/过程化计算： 最高能达到 22 倍的性能增益。
下一篇
SirixDB：给数据库加个 Git 版本管理 →
exec_stmt 的分发，这种开销在处理大规模数值计算时简直是灾难。最近在研究如何降低公司数据库层的计算成本，关注到了 uplpgsql 这个项目。它最核心的逻辑是绕过了 Postgres 原生的 JIT（因为原生的 JIT 对控制流优化有限），直接通过自己的 LLJIT 实例将控制流编译成原生代码。
从性能数据上看，这种 A vs B 的对比非常激进：
对我这种在意性价比的技术创业者来说，如果能通过编译器优化减少 CPU 占用，意味着在同等负载下可以降低数据库实例的规格，这比单纯地增加内存要划算得多。而且它不需要在编译 Postgres 时开启 --with-llvm，部署门槛降低了很多。
目前这个项目还处于 super-pre-alpha 阶段，甚至是在 PostgreSQL 20devel 上构建的，绝对不能直接上生产环境，但其技术路径给了一个很明确的信号：存储过程的执行效率不再是不可逾越的墙。
如果想在测试环境尝试，配置方式是使用 LANGUAGE uplpgsql 代替传统的 plpgsql。
CREATE FUNCTION my_heavy_calc() RETURNS void AS $$
BEGIN
-- 你的复杂逻辑
END;
$$ LANGUAGE uplpgsql;