介绍Fillfactor前先帮助大家回顾一下，Postgresql数据库的物理结构。
在了解了以上概念以及Postgresql数据库的物理结构后，我们可以更好地理解Fillfactor。
1. Fillfactor是一个表存储参数，对于性能方面，这是最重要的参数之一。
表的Fillfactor是介于10和100之间的百分比。默认值是100。
由于默认值为100，这意味着数据库会在页面中写入数据直到它没有剩余空间。因此在执行一个UPDATE时，旧元组将被标记为已删除，并且新元组将插入另一个页面。另外一个影响是，需要修改新记录的相关索引，因为索引必须指向新的位置。
还记得前面我们提到过的，对于一个UPDATE实际上有三个操作，首先标记已删除的元组，在新页面中写入新元组，以及索引修改。这不仅仅和UPDATE相关，实际上SELECT查询的性能也会因内部碎片而降低。
--查看表或者索引的Fillfactor值
如果设置了Fillfactor，你可以找到“{fillfactor = value}”，否则它只是NULL。
默认的Fillfactor是100，这个设置相对来说比较稳妥，但不是在所有情况下都是如此。
当表频繁更新时，你需要更多的CPU和IO用于不同的数据页操作这势必会影响性能。
解决方案是首先测量元组的大小，如果元组大小不是那么大，我们可以减少默认Fillfactor的值。
2. 如何衡量PostgreSQL中元组的大小？
在更改Fillfactor的默认值之前，我们应该测量表行的大小。如果表行较大，我们不应该更改Fillfactor的默认值。当我们进行性能优化时，知道page和堆表行的大小非常重要，否则我们需要处理高碎片并一次又一次地执行VACUUM FULL或VACUUM。
如果总行大小低于8kb，则可以尝试更改表存储参数。
使用下面的SQL查看行大小：
3. 如何在PostgreSQL中更改Table Fillfactor的当前值？
请注意：
更改Fillfactor的值后，只在特定表上执行VACUUM FULL。
更改Fillfactor的值后，它仅适用于新元组。
当我们减少Fillfactor的默认值时，每个页面都有一些空闲空间，UPDATE生成的新元组可以存储在同一页面上，索引页面就不需要任何修改，但是这也会导致数据文件比正常情况要更大，当做全表扫描时会导致访问更多的page，这些就需要运维人员进行性能测试，自行判断是否应该修改该参数。
