我需要知道是否有人有任何一般的指导方针(除了试验和错误)，为一系列查询类型在Greenplum中定义最佳分区/索引的良好策略?
Greenplum对他们的管理指南有一些建议…但事实是，它几乎是postgres文档的复制粘贴，虽然它的一些建议看起来很明显(例如:当表太大而无法容纳内存时进行分区)，但它不足以定义一个好的策略来实现这一点。
通常Greenplum数据库有非常大的表(超过数百gb)，虽然硬件是专门为这种用途而选择的，但大多数时候我遇到的问题是，当涉及到真正的大型数据库(IE:曾经有一个数据库，有60个字段表和超过20亿行，每天增加400 - 800万个注册表)。
我知道有一些选择合适分区的技术，比如选择可预测的范围，这些范围将以几乎相等的大小分开(比如日期范围)。但是还有一个事实，当我尝试使用任何其他数据库依赖索引时，Greenplum完全不鼓励使用索引，因为它给一些设置更大的权重，比如它的随机页面成本，因此根本不使用索引。
但是我读到过一些情况，这是完全适得其反的:想象你有三个节点，每个节点64GB内存，根据GP，你不应该分区，直到表超过192，但由于没有使用索引，你最终将顺序扫描高达64GB每个节点!—虽然这仍然可以很快，如果你强制使用索引，你可以从超过20秒下降到几毫秒。
另一个已知的情况是，在进行分区时，开销使查询比应有的速度慢得多。
那么，回到最初的问题:
有人对如何定义分区/索引策略有什么好的、坚定的建议吗?
对于我们的一些ETL，来自源的测试查询可能会占用半个到整整一个小时，所以跟踪和错误确实会降低生产力。
谢谢。
我认为你的问题的答案不太依赖数学& &;更多关于用户如何访问表的信息。对于日期范围分区，如果用户通常查找一天的数据，那么每日分区是有意义的。如果用户通常查询较长的日期范围，那么每日分区只会增加开销。Greenplum DB表中的每个分区或子分区都被视为一个单独的表(因此也是文件系统上的一个单独文件)，因此为满足查询需要扫描的分区越多，需要访问的打开文件就越多。了解您的用户希望如何访问数据，这将为您提供关于可能的分区策略的更好线索。
混合分区策略也很有用。某些用例会倾向于一个表，其中有最近一周/一个月的每日分区，然后有较旧的分区覆盖较长的时间范围，因为它们被访问的频率较低，通常用于报告/分析查询，而不是行查找或类似。
就索引而言，虽然Greenplum DB的优化器更倾向于表扫描而不是索引访问，但在有些地方索引是有意义的。在某些情况下，我很幸运地使用了位图索引。
不幸的是，调优GPDB仍然是一门艺术形式，就像其他数据库一样，所以一定数量的试验&错误可能是不可避免的。