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の接続を再利用することで）より多くの接続を処理できるようにするためのものだと思いました。よくわかりません。

「このパラメータはメモリの最大50％である必要があります」など、PostgreSQLのwikiにあるアドバイスと同様のアドバイスを探しています。

これらの種類のパラメータを計算できるMySQLのスプレッドシートがあったことを覚えています。PostgreSQL / pgbouncerにそのようなものがあれば素晴らしいでしょう。

最初に、キャパシティプランニングに関する標準的な質問をお読みください。
^{_{求めている具体的なアドバイスは、キャパシティプランニングのアドバイスであり、特定の環境では、それを自分で解決する必要があります。}}

第二に、あなたはこの間違った見方をしています。
使用するメモリ（または他のリソース）の量は、設定する接続の数を決定するものではありません。必要な接続の数は、購入するサーバーの性能を決定します。
接続ごとのリソース要件は、マニュアルにかなり詳細に記載されており、リンク先のWikiでも説明されています。環境に必要なものを把握し（または経験に基づいた推測を行い）、実行するハードウェアがその環境で処理するものを処理できることを確認します。

具体的には、接続制限とプールサイズについては、単一サーバー上またはプール/バウンサーを介して、アプリケーションの要件を満たす「十分な」接続が必要です。

「十分」は相対的な数です。1つの接続を作成する（および継続的に再利用する）アプリケーションは、1つの接続のみを必要とします。ログインする各エンドユーザーに接続を確立するアプリケーションには、ユーザーと同じ数のDB接続が必要です。

Postgresとの両方のデフォルト値はデフォルトpgbouncerとして賢明です：

• Postgresを環境に投入する一般的な人にとっては、100個のデータベース接続は大量です。
  開発者はおそらく10を超える必要はないでしょう。他の誰もがその数を増やすのに十分なことを知っているでしょう。

• pgbouncerDBプールごとに20の接続があるということは、1つのサーバーを指す4つのプールを取得でき、デフォルトのPostgres接続制限を超えないことを意味します。
  複数のプールされたリソースがpgbouncer1つのバックエンドデータベースを指すようにすることができ、バックエンドサーバーで利用可能な接続を常に必要とします。

デフォルトが環境に適していない場合は、変更することが期待されます。

プールされた接続は、「使用可能なすべてのデータベース接続を常に拘束する」ことを意味しないことに注意してください。
指摘したようにpgbouncer、接続を再利用することがポイントです。ここでの効率の向上には、利用可能なすべての接続を結び付ける必要はありません。単に、切断、再接続、SSLの再ネゴシエーション、データベースへの再認証、接続設定クエリの再実行を行わないだけです。

ドキュメントの定義に注意してくださいdefault_pool_size

ユーザー/データベースのペアごとに許可するサーバー接続の数。

したがって、デフォルト構成が合計100接続のうち20のプールサイズである場合、これは5つの異なるユーザー/データベースペアが全体の制限に達する前にそれぞれのプールサイズを最大にする必要があることを意味します。逆に、たとえば、pgbouncerを使用して1人のユーザーを介して1つのデータベースにルーティングする場合、有効な接続制限は100ではなく20なので、それに応じてそのユースケースのプールサイズを設定する必要があります。YMMV。