CLUSTER 对性能的影响

Question

我正在尝试优化我的 Postgres 9.2 数据库以加快具有日期限制的查询。

我有一个timestamp专栏，但主要是我要求某一天，所以我创建了一个timestamp用于date解析的索引：

CREATE INDEX foo_my_timestamp_idx
ON foo
USING btree
((my_timestamp::date) DESC);

现在，为了提高性能，我CLUSTER foo使用上面的索引表：

CLUSTER foo USING foo_my_timestamp_idx;

根据手册上SQL-CLUSTER，表

根据索引信息进行物理重新排序

我想知道是否会对使用表 PK 的其他查询的性能产生影响（比如说id_foo）。有什么缺点吗？

Answer 1

是的，可能有缺点。如果另一个查询查看不是由日期确定的不同数据段，如果行现在分布在更多数据页上，则可能会影响性能。与您第一次查询利润的方式相同。这完全取决于您问题中没有的信息。

使用表 PK 的其他查询（比如 id_foo）

那可以是任何东西。这取决于您拥有什么以及您确切查询的内容。查询单行不会以任何方式受到影响，但多行可能会受到影响。

请注意，CLUSTER在原始条件下重写表VACUUM FULL（删除死元组，压缩表的物理大小，重写索引）因此您可能会看到对读取性能的直接积极影响，而与排序顺序无关。（很像你会得到的VACUUM FULL。）
之后CLUSTER，你可能想要VACUUM在表上运行一个普通的来更新可见性地图- 这可能允许仅索引扫描。

CLUSTER随写入频率收缩的所有好处。

此外，如果您对表进行了多次更新，CLUSTER则通过删除同一数据页上的热更新的“摆动空间”实际上可能会损害写入性能。您可以使用FILLFACTOR低于 100的设置来抵消这种影响。同样，取决于更新行的位置等。

有关的：

• 日期索引优化

无论哪种方式，我可能都不会在 上建立索引和集群my_timestamp::date，而是my_timestamp直接在上。没有失去，得到了一些。演员表非常便宜，但根本不演员表仍然便宜。并且索引可以支持更多的查询。

CREATE INDEX foo_my_timestamp_idx ON foo (my_timestamp);

即使 adate在磁盘上只占用 4 个字节，atimestamp占用 8 个字节，但对于您的情况，对齐填充通常会丢失差异，并且两个索引的大小完全相同。

由您的表达式索引产生的同一天多行的顺序是任意的。仍然可以有两个相同的时间戳，但通常不太可能有 6 位小数。除此之外，您可以获得确定性的行顺序，这具有多种优势。

我还删除了DESC关键字，因为 Postgres 可以几乎和向前一样快地向后读取索引。（不过，排序顺序对多列索引很重要！）更多：

• 优化对一系列时间戳的查询（两列）

代替：

SELECT * FROM foo
WHERE my_timestamp::date = '2016-07-25';

您现在将使用：

SELECT * FROM foo
WHERE  my_timestamp >= '2016-07-25'  -- this is a timestamp literal now
WHERE  my_timestamp <  '2016-07-26';

一样的表现。

如果您不需要列的时间分量可言，转换列date...

如何回滚CLUSTER？

CLUSTERROLLBACK只要事务尚未提交，就可以像任何其他常规命令一样回滚单个表。

但是，我引用了手册：

CLUSTER如果没有任何参数，则重新聚集调用用户拥有的当前数据库中所有先前聚集的表，或者如果超级用户调用所有此类表。这种形式的CLUSTER不能在事务块内执行。

您始终可以CLUSTER使用不同的索引运行以再次更改行的物理顺序。