PostgreSQL：我什么时候应该对 SSD 上的表使用 fillfactor < 100？

Question

PostgreSQL 文档说，选择较小的fillfactor表可以为同一页面上的未来更新保留空间，并且

“这让 UPDATE 有机会将行的更新副本与原始行放在同一页上，这比将其放在不同的页上效率更高。”

事实上，如果集群存储在常规 HDD 驱动器上，这可以提高 UPDATE 性能，但我的是在 SSD 上。据我所知，设置fillfactor < 100不会给我任何性能优势，只会浪费（相对）昂贵的存储空间。

你对我的案子有反例吗？

Answer 1

您正在解决由随机访问引起的性能问题，正如您所指出的，通过使用 SSD 完全消除随机访问的成本，可以很好地解决这个问题。但是，postgres 确实提供了“仅堆元组（热）更新”（这里和这里和这里的一些注释），这可能会使您受益于填充因子小于 100%，而不管物理介质如何，如果您适度地更新到频繁（越频繁，节省越多）并且这些更新不会影响任何索引列。

想象一下，如果填充因子恰好为 100%，并且随着时间的推移，您的表格数据恰好填充了一页。在下一次更新时（假设它只有一行），将更新行的副本复制到下一页，而原始行保留在当前页上；如果事务已提交，则该行的更新前版本被标记为死以被真空删除，更新后版本被标记为活动。现在，假设更新仅影响特定 PK 值的“data_value”列，例如update table_name set data_value = 1 where pk = 3. 在这种情况下，数据的堆位置更改了页面，因此必须更新支持 PK 约束的索引以反映该更改。无论物理介质如何，这都是潜在的性能损失。此外，这个死元组会一直存在，直到真空回收空间。

使用 HOT 更新，只要您不更新索引列，数据库就可以通过将更新后元组与更新前表保持在同一页面上来避免更新索引条目，这可以加快更新速度。最重要的是，HOT 更新提供了一些自动维护，并使页面没有死行，减少了清理和自动清理的需要。

此外，即使在数据访问的情况下，您仍然可以从数据本地化中受益。即使从 SSD 读取随机页面所需的时间可以忽略不计，但必须执行多次读取仍然（许多 * 可以忽略不计的时间）比仅读取保存数据所需的最少页面量更昂贵。