Comparing Postgres connection pooler support for prepared statements
summary
Postgres poolers PgBouncer, Odyssey, pgcat and Supavisor now support prepared statements but with different designs and tradeoffs: Odyssey remaps client names to unique server names and re-prepares on new server connections to avoid conflicts (connection-level naming), PgBouncer implements the feature with many edge-case fixes and shows >2x throughput for prepared queries on a single process and even better with Multi-PgBouncer, Odyssey and Multi-PgBouncer give ~25–30% gains, pgcat re-prepares every time causing memory bloat, and Supavisor only supports SQL-level prepared statements not the common protocol-level prepared statements.
AI-written summary · about
chapters (9)
- 0:00Intro
- 0:42What are connection poolers?
- 2:17What are prepared statements?
- 4:03Why is it difficult with transaction pooling?
- 6:03What options are there?
- 9:01Time to optimize!
- 13:41So many edge case bugs!
- 18:34What about performance?
- 21:25Which pooler handles prepared statements best?
related talks
59mComparing Connection Poolers for PostgreSQL
20mElephant by the pool: PostgreSQL connection poolers overview
30mNew features of the Odyssey connection pooler
46mOdyssey — a scalable connection pooler for PostgreSQL
46mPgBouncer Connection Pooling and Routing
51mConnection pooling routing and queueing with pgBouncer
53mPgBouncer: Present and Future
42mDo it in SQL: pgbouncer_wrapper