Postgres的savepoint，怎么就成了队列的隐形杀手？

队列明明设计得没问题，吞吐为什么就是上不去？翻了一堆日志，最后定位到Postgres的savepoint——那个随手用来做子事务回滚的"便利功能"。incident.io踩了这个坑：每次入队操作包在savepoint里，Postgres得为每个子事务维护额外的回滚日志和资源锁。队列越大，排队越久，吞吐越低。更阴的是，这种损耗是渐进式的，压测时未必暴露，生产流量一上来就明显卡顿。说白了，Postgres对并发子事务的支持，从来没为高吞吐队列场景做过优化。别拿"数据库原生支持"当免死金牌——性能黑洞往往藏在最不起眼的便利特性里。

原文：Sub-transactions throttled our Postgres-backed queue · 来源：Hacker News