问缓存表的填充因子是什么？

EN

这里的关键词是：

1. “大量更新”
2. “在桌子上待2-3小时”。

点1表示填充系数较低，而2则相反。如果在同一数据页上存储多个行版本，则有助于性能。H.O.T.更新将实现这一目标。阅读这里或这里。它们需要在数据页面上有一些回旋的空间--就像死元组或由fillfactor < 100所保留的空间。但是，如果没有索引涉及任何更新的列，则它们只能执行它们的操作，这对于您的情况应该是正确的。

这里的另一个重要因素是元组大小(与页面大小(最常见的是8kb)相比)。有关答案的更多细节如下：

• 度量PostgreSQL表行的大小

如果元组大小为4kb或更多，降低填充因子将是徒劳无功的，因为数据页上不可能有超过一个元组。您最好把它留在100 (反正这是默认的)。然而，如果一些数据类型被“烤”了。和存储超出了一个大小限制，那么在主关系叉中需要这么多的元组是很少见的。

无论您做什么，VACUUM都会经常运行。这是一件好事，我不担心。你创造了很多死元组。VACUUM标识不再对任何打开的事务可见的死行。手册：

标准形式的VACUUM删除表和索引中的死行版本，并标记可供将来重用的空间。

大胆强调我的。

您可以使用每表设置用于自动真空来更少(或更多)地触发它，只用于此表：

默认的阈值和比例因子是从postgresql.conf中提取的，但是可以在表的基础上覆盖它们；

大胆强调我的。特别是对于autovacuum_vacuum_threshold和autovacuum_vacuum_scale_factor。大量运行VACUUM实际上可能是一个好主意，而不是一个非常低的fillfacter。这取决于访问模式。如果所有的元组都运行了3小时，并且每个元组都被更新了几次，我仍然会将fillfactor降低到大约50。你得试一试才能找到那个好地方。

Alternatives

撇开这一切不说，因为您的数据似乎是不稳定的，首先:使用UNLOGGED表格：

写入未登录表的数据不会写入预写日志(请参阅第29章)，这使得它们比普通表快得多。然而，它们并不是崩溃安全的:未登录的表在崩溃或不干净的关闭后会自动被截断。未记录表的内容也不会复制到备用服务器。

大胆强调我的。如果您的服务器可能崩溃，并且之后仍然需要数据，请不要使用此方法。但是，如果我们讨论的是web应用程序的会话数据，这可能是一个可以接受的代价。

或者，更根本的是:如果您可以完全没有RDBMS提供的特性和安全性，就可以使用类似于Redis的键值存储。

我建议建立一个键值数据库管理系统，但为了利益起见，我把它扔出去了。

而不是执行INSERT和DELETE语句，而是只执行更新。

表的结构将类似于

ID      integer  -- sequential ID
Used    boolean  -- default FALSE
Object  -- whatever type is appropriate

持有对象的列将具有固定的长度，以避免拆分和行移动。调整列的大小以容纳对象，并有效地填充磁盘上的页。

用你需要的尽可能多的行和更多的行预先填充你的表。

当要写入对象时，请查找带有Used = False的行，并更新该行。当要销毁对象时，将其设置为"False“。没有创建垃圾，因此也没有垃圾收集。

当然，需要处理的异常条件很多(行溢出、表溢出、ID使用的争用条件等)。但没有一个是不可逾越的。