0

我试图弄清楚为什么没有对超过 100 万行的表执行任何分析工作。如果我运行以下查询：

select count(*) from variant

我明白了1,668,422

但是，当我检索同一张表上的统计信息时：

SELECT relname,
n_tup_ins, n_tup_upd, n_tup_del,
n_live_tup, n_dead_tup,
last_vacuum, last_autoanalyze
FROM pg_stat_user_tables WHERE relname = 'variant';

          relname           | n_tup_ins | n_tup_upd | n_tup_del | n_live_tup | n_dead_tup | last_vacuum | last_autoanalyze
----------------------------+-----------+-----------+-----------+------------+------------+-------------+--------------
 variant_analysis_dependent |    140514 |       530 |         0 |     140514 |        104 |             | 
(1 row)

我们可以看到没有进行任何分析。然后我的期望n_tup_ins是等于或大于第一个查询的行数（并且n_live_tup相等）。也n_tup_ins - n_dead_tup应该等于n_live_tup

我有以下设置值：

SELECT name, setting, short_desc from pg_settings where category like 'Autovacuum';
                name                 |  setting  |                                        short_desc                                         
-------------------------------------+-----------+-------------------------------------------------------------------------------------------
 autovacuum                          | on        | Starts the autovacuum subprocess.
 autovacuum_analyze_scale_factor     | 0.1       | Number of tuple inserts, updates, or deletes prior to analyze as a fraction of reltuples.
 autovacuum_analyze_threshold        | 50        | Minimum number of tuple inserts, updates, or deletes prior to analyze.

因此，即使使用统计数据中的元组计数，如果我们应用公式autovacuum_analyze_scale_factor * number of tuples + autovacuum_analyze_threshold，我们应该得到0.1 * 140514 + 50 = 14101.4, 小于n_tup_ins = 140514，因此应该触发分析作业，对吗？

我在这里想念什么？

4

1 回答 1

0

公式中使用的“元组数”来自 pg_class，而不是 pg_stat_user_tables。因此，如果您的服务器崩溃，或者在“正确/错误”时间在其上调用了 pg_stat_reset() 或 kin，这个观察结果很容易解释。

于 2021-10-18T19:52:42.390 回答