小编fgb*_*ist的帖子

我正在处理一组可以移除孩子的关系，但我显然不想失去孙子和父母之间的联系。我确实考虑过将孩子标记为“已故”（在这篇文章中使用相关术语），但后来我最终会被困在我的数据库中的一堆已故孩子，谁想要这样（只是为了保持关系）？

如果删除父项，则删除其所有后代。此外，它的工作方式类似于“正常”关系，其中孙子和子项始终具有相同的顶级父级。层次结构固定为 3 个级别（如上所示）。最后，Parent、Child 和 Grandchild 都是不同的类型（例如，我们不是在谈论 3 个“人类”，他们没有相同的基础）。

然而，让孙子跟踪父母感觉有点奇怪，因为这种关系通常可以从父子关系中推导出来。虽然，我想不出另一种方法。

这个模型有效吗？或者有不同的方法吗？

我已经尝试对内置 upsert (INSERT ... ON CONFLICT UPDATE ...) 的性能影响进行了一段时间的研究，当进行了大量 upsert 时。规模大约是每小时 100 万条记录，分为每组大约 300 条记录。

该表相当简单，只有几个 int/bool 字段和一个日期字段。该表的总大小介于 50-6000 万条记录之间。本质上，所有行都应该在某个周期（目前大约为 2 天）内保持最新。有时很多信息会发生变化，有时很少/没有信息变化（例如 300 条记录被更新，但它们与现有记录相同）。

到目前为止，一个假设是，这个项目似乎正在遭受不断发生的大量写入的痛苦，因为即使 upsert 导致没有插入/更新，来自 upsert 的“失败”插入仍然会被写入某个地方（根据我们的知识）。因此，我们的想法是利用老式的 upsert（可写 CTE）并执行更精细的操作，以确保仅插入尚不存在的数据，并且仅更新实际更改的数据。然而，这自然会给数据库带来更多的读取负载并增加查询的复杂性。

问题是，从性能的角度来看，内置 upsert 是无用的（例如，它只适用于更小的任务），我们的假设是正确的，还是我们错了？我阅读了一些关于 HOT 更新和 autovacuum 调整的内容，但没有任何内容引用与此问题更相似的内容。

值得一提的是，这个数据库（PostgreSQL 10.9）在 Heroku 上运行，所以我们无法根据需要对其进行调整。我们计划在某个时候搬家，这取决于它最终的重要性。最后，还值得一提的是，这个DB还有一个follower（即只读副本）。

真的很感激对此有一些好的见解！先谢谢了。