PostgreSQLのmax_connectionsとpgbouncerのdefault_pool_sizeの計算方法は？
max_connections、default_pool_size、max_client_connの適切な数値を計算するために使用できるルールまたは何かありますか？
デフォルトは奇妙です。 PostgreSQLのデフォルトはmax_connections = 100ですが、pgbouncerのデフォルトはdefault_pool_size = 20です。 default_pool_sizeは常にmax_connectionsより大きくあるべきではありませんか？それ以外の場合、ポイントは何ですか？ pgbouncerはオーバーヘッドを下げることで（PostgreSQLの接続を再利用することで）より多くの接続を処理できるようにするためのものだと思いました。よくわかりません。
PostgreSQLのwiki にあるようなアドバイスを探しています。たとえば、「このパラメーターはメモリの50％以下にする必要があります」などです。
この種のパラメータを計算できるMySQLのスプレッドシートがあったことを覚えています。 PostgreSQL/pgbouncerのようなものがあると素晴らしいでしょう。
まず、 キャパシティプランニングに関する標準的な質問を読んでください 。
あなたが求めている具体的なアドバイスはキャパシティプランニングのアドバイスであり、特定の環境に合わせて自分で解決する必要があります。
第二に、あなたはこれを間違って見ています。
使用しているメモリ（またはその他のリソース）の量は、設定した接続数、つまり必要な接続数には影響しませんあなたが購入しなければならないサーバーがどれほど頑丈であるかを指示します。
接続ごとのリソース要件は マニュアル にかなり詳細に記載されており、リンク先のWikiでも説明されています。環境に必要なものを理解し（または知識に基づいた推測を行い）、実行するハードウェアが、これに投入するものを処理できることを確認します。
具体的には、接続制限とプールサイズについては、アプリケーションの要件を満たす「十分な」接続が必要です-単一サーバー上か、プール/バウンサーを介して。
「十分」は相対的な数です。1つの接続を作成（および継続的に再利用）するアプリケーションは、1つの接続のみを必要とします。ログインするエンドユーザーごとに接続を確立するアプリケーションには、ユーザーと同じ数のDB接続が必要です。
Postgresとpgbouncerの両方のデフォルト値は、defaultsとして適切です。
100のデータベース接続は、Postgresを環境に投入する一般的な人にとっては多くのことです。
開発者はおそらく10を超える必要はないでしょう。他の誰もが数を増やすのに十分知っています。DBプールごとの
pgbouncerからの20接続は、1つのサーバーを指す4つのプールを取得でき、デフォルトのPostgres接続制限を超えないことを意味します。
1つのバックエンドデータベースを指すpgbouncerに複数のプールされたリソースを含めることが可能で、バックエンドサーバーで常にいくつかの利用可能な接続が必要です。
defaultsが環境に適していない場合は、それらを変更する必要があります。
プールされた接続は、「常に利用可能なすべてのデータベース接続を拘束する」ことを意味しないことに注意してください。pgbouncerのポイントは、reuse接続を再利用することです。ここでの効率の向上は、利用可能なすべての接続を結び付けることを必要とせず、単に切断、再接続、SSLの再ネゴシエーション、データベースへの再認証を行わず、毎回接続セットアップクエリを再実行するだけです。
注意 default_pool_sizeのドキュメントの定義
ユーザー/データベースのペアごとに許可するサーバー接続の数。
したがって、デフォルトの構成が合計100の接続のうち20のプールサイズである場合、これは、全体の制限に達する前に、5つの異なるユーザー/データベースのペアがそれぞれプールサイズを最大にする必要があることを意味します。逆に、たとえばpgbouncerを使用して単一のユーザーを介して単一のデータベースにルーティングする場合、有効な接続制限は100ではなく20であるため、そのユースケースのプールサイズをそれに応じて設定する必要があります。 YMMV。