在以下链接中，我使用的工具（Airflow）的创建者建议为维度表的每日快照创建分区。我想知道在Postgres做这样的事情的开销。
我在几个表中使用Postgres 10内置分区，但主要是每月或每年的事实。我之前从未尝试过为尺寸实现日常分区，这似乎很可怕。如果我需要重新运行旧任务，它会在几个方面简化事情。
简单。使用维度快照，其中附加了新分区 每个ETL时间表。维度表成为集合 维度快照，其中每个分区包含完整维度 作为一个时间点。 “但只有一小部分数据 每天都在变化，这就是大量的数据重复！“那就对了， 虽然通常维度表的大小可以忽略不计 事实。这也是解决SCD类型问题的一种优雅方式 它的简单性和可重复性。现在存储和计算都是 与工程时间相比，污垢便宜，快照尺寸使 在大多数情况下都有意义。
虽然传统的2型缓慢变化的维度方法是 从概念上讲，声音总体上可能更具计算效率， 管理起来很麻烦。围绕这种方法的过程就像 管理维度上的代理键并执行代理键 在加载事实时查找，容易出错，充满突变和 几乎不可复制。
答案 0 :(得分：2)
我使用过具有不同分区级别的系统。 通常任何分区都可以，只要您在分区上有检查约束，这允许查询规划器为查询找到足够的分区。或者，您必须直接查询特定分区以查找某些特殊情况。否则，即使是简单查询，您也会看到所有分区上的顺序扫描。
每日分区完全没关系，不用担心。我使用基于PG的数据收集器来处理事件，因为它每天收集几个TB，因此需要为每5分钟的数据分配一次。
只有当您拥有数千或数十万个分区时，分区数量才会成为一个更大的问题 - 这些分区数量一切都会遇到不同级别的问题。
您必须设置正确的max_locks_per_transaction，以便能够使用它们。因为即使是简单的select over parent表也会将SharedAccessLock放在所有分区上，这些分区并不是很好但PG继承可以这样工作。
加上更高的查询计划时间 - 在我们的数据仓库中，我们有时会看到几分钟的查询计划时间和只需几秒钟的查询 - 这有点令人讨厌...但由于当前的PG很难对它进行任何操作规划师以这种方式工作。
但PRO仍然超重CON，因此我强烈建议您使用所需的任何分区粒度。