このComputer World記事では、PostgreSQLが64のコア制限まで拡張できることを指定しています。これは、64コアの1つのマルチコアプロセッサを意味しますか？それともコアの少ないマルチプロセッサですか？

私が尋ねる理由は、PostgreSQLがスケールアップできるプロセッサの数を見つけようとしているためですが、もちろんそれはプロセッサのタイプに限定される可能性があります。ただし、他のデータベースで他の統計情報（つまり、ここでは Microsoft SQL Server が最大320の論理プロセッサに拡張できることを示す）を見つけており、コアの数を指定していません。これは非常にあいまいな統計ですか？

どんな考えでも大歓迎です。ありがとう！

いいえ、それは非常に正確な統計です。「論理プロセッサー」はコアです。コアはそれだけです。物理プロセッサにどのように分散しているかは問題ではありません。

サポートされている数よりも多くのコアを持つマシンを扱っている場合、これはPostgreSQLの問題ではありません。各接続は本質的にシングルスレッド *なので、コアの数がいくつあっても、同時接続の効率と効率は制限されます。

言うまでもなく、これは、より複雑な方法で物事をクラスター化したい場合を除き、コアの数よりも高速なコアにお金を投入する必要があることを意味します。

_{* 2017更新：一部のクエリ（またはサブクエリ）が並行して実行される場合があります。}

Postgresは、インストールしたい数のプロセッサまで拡張でき、OSは効果的に処理/管理できます。Postgresを128コアマシン（または128物理プロセッサを搭載したマシン）にインストールすれば、問題なく動作します。それはあり、OSのスケジューラは、多くのコアを扱うことができればさらに良い64コアのマシンよりも動作します。

Postgresがすることが示されているスケール 直線の注意事項を（64個のコアまで：我々は、（特定の構成では、読み取りパフォーマンスについてディスク、RAM、OSなど）を話している- ロバート・ハースは、素敵なグラフでブログ記事を持っています以下を再現しました：

このグラフの何が重要ですか？

クライアント数がコア数以下である限り、関係は線形（またはそれに近い）であり、クライアント接続数が多いほど、ほぼ線形にパフォーマンスが低下するように見えます。バックエンドがCPUを求めて戦い始めるため、コアを実行してPostgresバックエンドを実行します（負荷平均が1.0を超えるなど）。

これは最大64コアに対してのみ実証されていますが、コア（およびクライアント）を追加し続け、プロセスがもはや存在しない他のサブシステム（ディスク、メモリ、ネットワーク）の限界までパフォーマンスを改善し続けることができると一般化できます。 CPU競合の問題がありますが、代わりに何かを待っています。

（Haasはまた、32コアまでの線形スケーラビリティを証明した別の記事を持っています。これには、一般にスケーラビリティに関するいくつかの優れた参考資料があります-強くお勧めのバックグラウンドリーディング！）

他の人は、論理プロセッサは一般にCPUコアを指すことを明らかにしましたが、コアがCPUにどのように分散されているかは問題ではないという声明についてコメントしたいと思います。

コア間で共有されるか、コアの単一またはサブグループ専用のキャッシュをCPUダイ上に置くことができます。たとえば、1つの一般的な構成は、専用L1キャッシュと共有L2キャッシュです。この場合、シングルデュアルコアCPUのスケーラビリティは、2つのシングルコアCPUとは異なる場合があります。

これらのスケーラビリティは、NUMAマシンが非NUMAとは異なる動作を示すため、メインメモリに継続的に影響します。

私がこれらを指摘しているのは、OPがスケーラビリティの問題について議論しているからです。その答えは、一般に「プログラムXがY CPUコアを使用できる」よりも微妙です。

この場合、それらはより少ないコアを持つ複数のプロセッサを意味します...話のいくつかは将来を見据えています。一部はマーケティングの話です。