在以下链接中，我使用的工具的创建者(气流(建议为尺寸表的每日快照创建分区。我想知道在Postgres中做这样的事情的开销。
我使用的是在分区的几个表中构建的Postgres 10，但主要是在每月或每年的事实上进行。我以前从未尝试过每日分区的分区，这似乎很可怕。尽管我需要重新运行旧任务，但在我的几个领域中，这都可以简化事情。
https://medium.com/@maximebeauchemin/functional-data-egneering-a-modern-paradigm-for-batch-data-processing-2327ec32c42a
简单。使用尺寸快照，将新分区附加在 每个ETL时间表。尺寸表成为 每个分区包含完整维度的尺寸快照 作为时间点。"但是只有一小部分数据 每天变化，这是很多数据重复！"。这是正确的， 虽然通常尺寸表的大小比例可忽略不计 事实。这也是解决SCD型问题的优雅方法 它的简单性和可重复性。现在存储和计算是 与工程时间相比，污垢便宜，快照尺寸使得 在大多数情况下有意义。
传统的2型慢慢改变维度方法是 从概念上讲是合理的，总体上可能更有效， 这很麻烦。围绕这种方法的过程，就像 在维度上管理替代键并执行替代密钥 加载事实时查找，容易出错，充满突变，并且 几乎无法再现。
我已经与具有不同分区级别的系统合作。通常，只要您对分区有支票约束，允许查询计划者可以找到足够的查询分区，则任何分区。或者，您必须在某些特殊情况下直接查询特定的分区。否则，即使在简单的查询中，您也会看到所有分区上的顺序扫描。
每日分区完全可以，不用担心。我是根据PG与数据收集器一起工作的，该活动需要每5分钟的数据进行分区，因为它每天收集几个TBS。
只有当您拥有数千个或数十万个分区时，数量的分区才能成为一个更大的问题 - 使用此数量的分区，一切都陷入了不同的问题。
例如，您必须设置正确的max_locks_per_transaction才能与它们一起使用。因为即使是简单的选择对父表的选择都放置在所有分区上的sharedAccesslock，这并非完全不错，但是PG继承可以使用。
加上较高的查询时间 - 在我们的数据仓库中，我们有时会看到诸如几分钟之类的查询时间的计划时间，而查询只需几秒钟 - 这有点磨碎...但是很难用它来做任何事情，因为当前的PG计划者这样工作。
但优点仍然超重，所以我强烈建议使用您需要的任何分区粒度。