我需要知道是否有人有任何一般准则（除了反复试验），用于为 Greenplum 中的一系列查询类型定义最佳分区/索引的良好策略？
Greenplum 对他们的管理指南有一些建议......但事实是，它几乎是来自 postgres 文档的复制粘贴，虽然其中一些建议似乎很明显（IE：当表太大而无法放入内存时进行分区），它是仅仅定义一个好的策略来实现这一点还不够。
通常 Greenplum 数据库有非常大的表（超过数百 GB），虽然专门为这种用途选择了硬件，但大多数时候我在涉及到非常大的数据库时遇到了麻烦（IE：曾经有一个数据库有 60 个字段的表和超过 2 亿行，每天增加 4-8 百万个注册表）。
我知道选择合适的分区有一些技巧，比如选择可预测的范围，这些范围将以几乎相等的大小分隔（如日期范围）。但还有一个事实是，当我尝试依赖索引的任何其他数据库时，Greenplum 通过给予某些设置更大的权重来完全阻止它们，比如它的随机页面成本，因此根本不使用索引。
但是我读过一些完全适得其反的情况：假设您有三个节点，每个节点 64GB 内存，根据 GP，您不应该分区，直到表超过 192，但由于未使用索引，您最终会seq 每个节点最多可扫描 64gb！--- 虽然这仍然可以很快，但如果你强制使用索引，你可以从 20 多秒减少到几毫秒。
另一个已知情况是，在分区时，开销使查询比应有的速度慢很多。
那么，回到最初的问题：
是否有人对如何定义分区/索引策略有任何好的、坚定的建议？
使用我们的一些 ETL，来自源的测试查询可能需要半小时到一整小时，因此跟踪和错误确实会降低生产力。
谢谢。