This is a deep and excellent post. Thanks for publishing it and all the research required. Maybe too much 30,000 feet perspective, but in general everything th

This is a deep and excellent post. Thanks for publishing it and all the research required. Maybe too much 30,000 feet perspective, but in general everything that is "state" in a session is a potential limit to performance and scalability. In this blog post, it is the "state" associated with subtransactions. In another area, it may be Prepared Statements. Often regarded as better performing than non prepared (and they strictly are, generally), they impose hard limits into connection scalability. Connection poolers cannot hold this state and thus you cannot use transaction pooling, which boosts performance and resource usage much more than prepared vs non-prepared. Anyway, that's another topic. But session state --is something I'm becoming more and more against. YMMV.