接続プール担当者は、リクエストごとに行われる接続と切断のオーバーヘッドを節約するだけでなく、多数のクライアント接続を少数の実際のデータベース接続に集中させることができます。 PostgreSQLでは、アクティブなデータベース接続の最適な数は通常、（（2 * core_count）+effective_spindle_count）前後です。 。この数値を超えると、スループットと遅延の両方が悪化します。
「2000人のユーザーを迅速な応答時間でサポートしたい」と言う人もいます。 2000の実際のデータベース接続でこれを実行しようとすると、パフォーマンスがひどくなることはほぼ確実です。 4つのクアッドコアプロセッサを搭載したマシンがあり、アクティブなデータセットが完全にキャッシュされている場合、約35のデータベース接続を介してリクエストを処理することで、2000人のユーザーのパフォーマンスが大幅に向上します。
それが真実である理由を理解するには、この思考実験が役立つはずです。共有するリソースが1つ（単一のコア）しかない架空のデータベースサーバーマシンについて考えてみます。このコアは、オーバーヘッドなしですべての同時リクエスト間で均等にタイムスライスします。 100個のリクエストがすべて同時に着信し、それぞれに1秒のCPU時間が必要だとします。コアはそれらすべてで機能し、100秒後にすべてが終了するまでそれらの間でタイムスライスします。ここで、100のクライアント接続を受け入れる接続プールを前面に配置し、データベースサーバーに対して一度に1つの要求のみを行い、接続がビジー状態の間に到着した要求をキューに入れるとどうなるかを考えてみましょう。これで、100個のリクエストが同時に到着すると、1人のクライアントが1秒で応答を受け取ります。もう1つは2秒で応答を受け取り、最後のクライアントは100秒で応答を受け取ります。応答を得るのにこれ以上待つ必要はありませんでした。スループットは同じですが、平均遅延は100秒ではなく50.5秒です。
実際のデータベースサーバーには、並行して使用できるリソースが多くありますが、同じ原則が当てはまります。リソースが飽和状態になると、データベース要求を同時に追加することによってのみ問題が発生します。タスクが増えると、タスクスイッチが増え、ロックとキャッシュの競合が増え、L2とL3のキャッシュラインの競合が発生し、スループットとレイテンシの両方が低下する他の多くの問題があるため、実際には例よりも悪くなります。その上、高いwork_mem 設定はさまざまな方法でクエリに役立ちます。その設定は、各接続のプランノードあたりの制限です。 、したがって、接続数が多い場合は、キャッシュのフラッシュやスワッピングを回避するために、これを非常に小さくする必要があります。これにより、計画が遅くなったり、ハッシュテーブルがディスクに流出したりする可能性があります。
一部のデータベース製品はサーバーに接続プールを効果的に構築しますが、PostgreSQLコミュニティは、最良の接続プールはクライアントソフトウェアの近くで行われるため、これを管理するのはユーザーに任せるという立場を取っています。ほとんどのプーリーには、データベース接続をハード数に制限する方法がありますが、それよりも多くの同時クライアント要求を許可し、必要に応じてそれらをキューに入れます。これはあなたが望むものであり、トランザクションで実行する必要があります ステートメントや接続ごとではなく、基本です。