【发布时间】:2020-04-27 07:59:51
【问题描述】:
我的团队正在考虑将包含约 1TB 数据的非分区表移至分区表。
我们将使用基于时间戳列的范围分区。
我不明白的一件事是,如果时间戳列用作分区键,我们是否需要在时间戳列上添加索引。如果我们让我们的分区非常小(例如每天的分区),这是否会以类似于索引的方式起作用?
我们只会以一天的最大分辨率进行查询。
我不愿意添加索引,因为我们过去曾尝试过,但它从未完成(可能是因为我们没有关闭写入。不是真正长时间关闭写入的选项)。
【问题讨论】:
我的团队正在考虑将包含约 1TB 数据的非分区表移至分区表。
我们将使用基于时间戳列的范围分区。
我不明白的一件事是,如果时间戳列用作分区键,我们是否需要在时间戳列上添加索引。如果我们让我们的分区非常小(例如每天的分区),这是否会以类似于索引的方式起作用?
我们只会以一天的最大分辨率进行查询。
我不愿意添加索引,因为我们过去曾尝试过,但它从未完成(可能是因为我们没有关闭写入。不是真正长时间关闭写入的选项)。
【问题讨论】:
您的感觉是对的:省略分区列上的索引是分区实际上使查询更快的少数几个地方之一。
然后,您可以对单个分区进行顺序扫描,而不必使用每个数据修改语句来维护索引。
另一个优点是分区使大量删除数据(沿分区边界)变得更加高效。最后,autovacuum 的工作会变得更容易。
关于分区的两点:
升级到 v12;在分区方面已经有了实质性的性能改进。
不要使用太多分区。使用 v12,您可能会达到几千个,在早期版本中,您会更早遇到性能问题。
【讨论】:
Note that partition pruning is driven only by the constraints defined implicitly by the partition keys, not by the presence of indexes. Therefore it isn't necessary to define indexes on the key columns. Whether an index needs to be created for a given partition depends on whether you expect that queries that scan the partition will generally scan a large part of the partition or just a small part. An index will be helpful in the latter case but not the former.postgresql.org/docs/11/ddl-partitioning.html