Názor k článku PostgreSQL 17: pádící slon nezpomalí od Pavel Stěhule - To je historicky dané. Postgres connection pool neměl...

To je historicky dané. Postgres connection pool neměl - víceméně se předpokládalo, že pokud bude potřeba, tak se použije aplikační connection pool - PHP, Java, a smyslem bylo snížení režie connectu, nikoliv overloading spojení, který vůči Postgresu nedává moc smysl, jelikož Postgres nemá řízení zdrojů, prioritizaci zdrojů. Pro aplikace, které vlastní pooling neměly, tu byl dostačující pgbouncer. Bohužel pooling v Javě je takový, že než se aplikace rozjede, tak si vezme 200 spojení, a pokud máte 5 aplikačních serverů, tak máte 1000 spojení do pg (z toho je reálně použito 10), ale Javovský pooler refrešuje a prostřídává všechny, takže to generuje dost zbytečné režie, a tak je potřeba ještě jeden pooler, který dokáže tuhle režii eliminovat. pgbouncer je relativně hodně lehký, ale u pár tisíc spojení se začne zadrhávat, jelikož jede v jednom vlákně. Další poolery zvládají výrazně větší zátěž, ale mají samy větší režii než pgbouncer.

Další věc je ta, že Postgres nemá podporu vláken, a napsat pooler bez vláken na stávající architektuře dost dobře nejde - jinak skončíte jako pgbouncer na výkonu jednoho CPU. Dneska už bude situace jiná, ale před 15-20 roky, kdy bylo víc prostoru na architekturu, tak nebyla API pro management vláken na těch platformách, kde Postgres bežel. Teď to bude jednodušší, jelikož většina starých Unixů už je nepodporovaná.