我们知道GPDB通过给定的散列键将db项分配到几个段中。我确信它会为条件查询提供更好的性能，特别是对于那些具有给定分布式键/字段的查询，因为它可以大大减少扫描范围。
但是全盘扫描怎么样？例如，select count(distinct aField) from table，或select aField, count(distinct bField) from table group by aField，......等等 - 没有条件的查询。
因此，所有段都被完全扫描，查询结果将被发送到主站以通过网络进行聚合。我们可以从这种情况中获益吗？
Greenplum可以非常快速地处理顺序扫描，并且当您的数据跨段分布时，这意味着小块数据将被多个段并行扫描。
更不用说您可以使用正确的“行/列”方向组织数据，这可能会导致更小的数据扫描。
此外，如果您正在谈论大量数据，您可能会使用分区表，这意味着更快的结果。
由于Greenplum是用于parallel query execution at multiple segments的PostgreSQL的一个分支 - 如果实际查询的数据分布在它们之间 - 它基本上可以利用来自多个磁盘系统和单个节点的缓存的增强的执行性能。发送到主节点和最终查询处理的数据的开销以及必须准备每个节点的查询并将其发送以进行处理的主节点通常很小，但是如果需要最终排序的非聚合查询需要增加很多由主人完成。
然而，正如他们最近发布的上游PostgreSQL代码merged in version 9.4一样，Greenplums的性能声称的主要问题是它与PostgreSQL版本相比，这个版本对任何关心性能并且不受益于任何parallel query改进的人来说太老了。从版本9.6开始介绍。
每个主机的多个段在这里也没有多大帮助，因为每个段对同一主机上的其他段一无所知，因此竞争资源（磁盘I / O，内存操作，CPU缓存，网络，... 。）或者你实际上必须使用limit it a lot per segment as recommended，这可能会让你发疯，因为有些查询只会溢出到磁盘上。正确配置的单个PostgreSQL 11安装应该在单个节点上优于任意数量的Greenplum段，因为它具有更多可用的总缓存并且实际上知道它。
TL; DR
PostgreSQL上游近年来得到了很多改进，对于特定的用例，请考虑使用扩展而不是完整的分支。
此外，如果你担心count(distinct ...)的表现，你应该密切关注how you are counting。