我正在尝试了解 btree 索引的填充因子。从 postgres 文档中：

对于 B 树，在初始索引构建期间以及在右侧扩展索引（添加新的最大键值）时，叶页被填充到这个百分比。

首先，向右扩展索引是什么意思？这是否意味着分裂B树中最右边的叶子？（图像会有所帮助）。

为什么在这种情况下会考虑填充因子，而不是仅在创建索引时才考虑？

据我所知，postgresql 在创建过程中会考虑填充因子。例如，填充因子 = 50%，在创建索引后，叶最多将充满 50%，然后，对于新的插入，此参数将不被考虑（预期此“右扩展”）。

HOT 和 FILLFACTOR 结果

我有一些高 UPDATE 表，我已将其调整FILLFACTOR为 95%，我正在重新检查它们。我认为我的设置不正确，并且不清楚如何智能地调整它们。我又通过了 Laurenz Albe 关于 HOT 更新的有用博客文章

https://www.cybertec-postgresql.com/en/hot-updates-in-postgresql-for-better-performance/

...以及清晰的源代码阅读我：

https://git.postgresql.org/gitweb/?p=postgresql.git;a=blob;f=src/backend/access/heap/README.HOT

下面是一个查询，改编自博客文章，用于检查系统中表的状态，以及一些示例输出：

几个结果：

我不确定我在这里寻找什么比率。谁能告诉我如何阅读这些结果，或者阅读什么来弄清楚如何解释它们？

这些更新是 HOTable 吗？

我没有在这个问题的原始草案中解决这个基本点。几个月前我检查了我的补丁，然后我跑了SET (fillfactor = 95)，然后VACUUM (FULL, VERBOSE, ANALYZE)在我的 13 张桌子上跑。（VERBOSE因为我有一些桌子VACUUM因为需要清理几个月的流程而无法使用，这就是我发现问题的方式。pg_stat_activity是我的朋友。）

但是，至少大多数都触及索引列......但具有相同的值。像1 = 1，所以值没有变化。我一直认为那是 HOTable。如果我错了，那就糟透了。如果不是，我主要希望澄清 , 和 之间关系的确切目标fillfactor是n_tup_upd什么n_tup_hot_upd。

结果：

（我只是在https://www.tablesgenerator.com/text_tables寻找并找到了一个在线表格生成器来帮助解决这种示例。使用起来有点尴尬，但比手动构建等宽对齐文本更快.)

FILLFACTOR 和 HOT 更新率

我想我可以通过改编来自https://www.cybertec-postgresql.com/en/hot-updates-in-postgresql-for-better-performance/的 Laurenz Albe 的代码来解决这个问题。我在这里所做的只是制作一个脚本，用FILLFACTOR10、20、30 .....100% 构建一个表，然后以相同的方式为每个百分比更新它。每次创建表时，都会填充 256 条记录，然后每条记录更新 10 次。更新将一个非索引字段设置回自身，因此实际上没有值更改：

以下是结果：

由此看来，当total_to_hot比率上升时，增加FILLFACTOR.

https://www.postgresql.org/docs/13/monitoring-stats.html

n_tup_upd计算所有更新，包括 HOT 更新，并且n_tup_hot_upd只计算 HOT 更新。但这似乎不算“如果我们没有用完页面上的空间，这可能是一个热门更新”。那会很棒，但似乎也有很多要求。（也许跟踪它的成本更高是合理的？）

这是脚本。我对每个FILLFACTOR.

检查 FILLFACTOR 设置

作为旁注，我想快速打电话检查FILLFACTOR桌子上的设置，结果发现它比我想象的要复杂。我写了一个有效的函数，但可能会看到一些改进......如果有人有建议的话。我这样称呼它：

或者

这是代码，如果有人可以提供改进：

快速估算尺寸？

我正在研究FILLFACTOR调优，因此试图弄清楚如何计算 Postgres 中的平均行大小。我用这个线程作为起点：

https://dba.stackexchange.com/questions/23879/measure-the-size-of-a-postgresql-table-row

毫不奇怪，最准确的方法需要很长时间，我想知道是否有一种方法可以快速获得合理准确的估计？而且，就 而言FILLFACTOR，什么是最好的衡量标准？似乎索引和 TOAST 大小没有进入它。

到目前为止我已经尝试过：

• 基于 Erwin Brandstetter 上面引用的线程中的详细示例的多结果函数，table_get_info在此处命名。缓慢，但详细而准确。

• AVG(pg_column_size(table_name.*))，也来自那个线程，在这里实现为table_get_row_size_estimate. 慢，但没那么慢。

• avg(length(table_name::text),TABLESAMPLE在这里实现为table_get_row_length_estimate. 变速...精度取决于样品/运气？

示例查询

我知道这是低效的，这对这个测试很好。只是想得到一些比较结果。

结果

live_rows_in_text和的结果table_get_row_length非常相似，因为它们做的事情大致相同。这很慢，因为 Postgres 必须测试很多或所有行。估计（最右边的列）使用TABLESAMPLE，但它仍然很慢。

是否有一个快速的替代方案足以进行FILLFACTOR估算？FILLFACTOR并且，如果不是，什么度量对估计最有意义？

我已经包含了接下来使用的每个函数的代码。

table_get_info

提出了调整时要检查什么的问题FILLFACTOR。

table_get_row_size_estimate

我在这里尝试TABLESAMPLE过，它没有引起错误。虽然没有加快任何速度。

table_get_row_length_estimate

我正在尝试这样做以访问TABLESAMPLE. 我认为 8% 是合理估计的一个很好的默认值。