不，这是一个非常精确的统计。 一个“逻辑处理器”是一个核心。 而一个核心就是这样，它们如何分布在物理处理器上并不重要。

如果你使用的核心数量多于支持的核心数量，那么PostgreSQL不应该是这个问题。 每个连接本质上都是单线程的 *所以无论你拥有多less个核心，都会限制并发连接的效率和效率。

不用说，这也意味着你应该把你的钱放在比核心数量更快的内核上，除非你想用更复杂的方法把事情集中起来。

_{* 2017更新： 一些查询（或子查询）可能并行执行 。}

Postgres可以扩展到你想要安装的处理器数量，而你的操作系统可以有效地处理/pipe理。 你可以在一台128核心的机器上安装Postgres（甚至是一台有128个物理处理器的机器），它可以正常工作。 如果操作系统调度程序可以处理多个内核，它甚至可以比在64内核上运行得更好。

Postgres已经被certificate可以线性扩展到64核心（注意：我们正在讨论读取性能，在特定的configuration（磁盘，内存，操作系统等） – 罗伯特哈斯有一个很好的graphics博客文章我已经转载如下：

这个图表有什么重要的意义？

只要客户端的数量小于或等于内核数量，这种关系就是线性的（或几乎是这样），然后开始看起来大致是性能的对数线性下降 ，因为您有更多的客户端连接核心运行Postgres后端，因为后端开始争取CPU（平均负载超过1.0，等等…）。

虽然最多只能演示 64个内核，但是您可以概括说明您可以继续添加内核（和客户端），并不断改进性能，直到其他子系统（磁盘，内存，networking）的进程不再有争用问题的CPU，而是等待别的东西。

（ 哈斯还有另一篇文章，他们certificate了32位内核的线性可伸缩性，对于一般的可伸缩性有一些很好的参考资料 – 强烈推荐的背景阅读！）

其他人已经阐明，一个逻辑处理器通常是指一个CPU核心，但是我想评论一下，核心如何分布在CPU上并不重要。

您可以在CPU裸片上拥有在核心之间共享的caching或专用于单核或子核心组的caching。 例如，一个通用configuration是专用的L1caching和共享的L2caching。 在这种情况下，单个双核CPU的可扩展性可以不同于两个单核CPU。

这些可扩展性影响会持续到主存，NUMA机器performance出与非NUMA不同的行为。

我指出这些只是因为OP正在讨论可扩展性的问题，其答案通常比“程序X可以使用Y CPU核心”更细致。

在这种情况下，它们意味着多个处理器的内核数量更less……其中一些话题是面向未来的。 一些是营销发言。