基于表名的 Postgres 表分区

Posted 2023-03-31

【中文标题】基于表名的 Postgres 表分区

【英文标题】：Postgres table partitioning based on table name

【发布时间】：2019-07-24 05:26:31

【问题描述】：

我有一个表格，用于存储有关特定事件和特定时间戳的天气信息。我在这张表上插入、更新和选择（比删除更频繁）。我的所有查询都查询时间戳和 event_id。由于这张表正在爆炸，我正在考虑在 postgres 中进行表分区。

我还可以考虑拥有多个表并将它们命名为“table__”来存储特定的时间戳信息，而不是使用 postgres 声明/继承分区。但是，我注意到互联网上没有人做过或写过这样的方法。我有什么遗漏吗？ 我看到在 postgres 分区中，数据既保存在主表中，也保存在子表中。为什么要在这两个地方保留？对我进行插入和更新似乎效率较低。 当 postgres 开始阻塞时，表的数量是否有一般限制？

谢谢！

【问题讨论】：

“爆炸”有多大？

我正在计划第一阶段，我必须处理 1-20 亿行。以及 10-200 亿行的第 2 阶段。我可以在第 1 阶段完全不进行分区吗？

【参考方案1】：

re 1) 不要这样做。如果 Postgres 开发人员已经通过提供声明性分区为您完成了这项工作，为什么还要重新发明***

re 2) 你错了。数据仅保存在其所属的分区中。它只是看起来就好像它存储在“master”中。

re 3) 没有内置限制，但任何超出“几千”分区的东西都可能太多了。它仍然可以工作，但特别是查询 planning 会更慢。有时查询执行也可能会受到影响，因为运行时分区修剪不再那么有效。

根据您的描述，您可能希望对事件 ID 进行哈希分区，然后在时间戳值上创建范围子分区（因此事件的每个分区再次根据时间戳范围进行分区）

【讨论】：

但是，如果我的表名描述了分区，为什么不直接查询我的分区而不是主分区呢？这将减少查询计划时间，不是吗？

可能会减少查询计划时间，但很可能会增加查找时间，即如果表未打开，则打开文件，查找文件等。当文件数量达到数千时，只需打开一个文件就需要相当一段时间。所以不，表名只会增加你的复杂性

@DivyaKonda：那么每次针对不同事件运行查询时，您都需要更改 SQL 语句。如果你使用内置分区（而不是实现你自己的），你总是在你的选择中使用相同的表名，你只传递不同的参数，并且 Postgres 使用最好的计划来检索数据。您可以更改分区策略，而无需更改动态生成 SQL 查询的代码。相信我：你确实不想那样做。

@Aurangzeb 打开分区的过程不一样吗？所以，这两种情况下的寻道时间是一样的，对吧？

@a_horse_with_no_name 明白了。如果我使用声明式分区，但在执行插入或更新时指定分区表名称怎么办？那么查询计划时间会好很多，对吧？在代码中，我可以只使用一个生成表名称的函数。所以，如果我改变我的分区，我需要做的就是改变那个功能。