对于从未分析过的表，Postgres n_tup_ins与行计数不匹配
对于从未分析过的表，Postgres n_tup_ins与行计数不匹配
提问于 2021-10-18 16:08:54
我试图弄清楚为什么从来没有在超过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，所以应该触发分析作业，对吗？
我在这里错过了什么？
回答 1
Stack Overflow用户
回答已采纳
发布于 2021-10-18 19:52:42
公式中使用的“元组数”来自pg_class，而不是来自pg_stat_user_tables。因此，如果您的服务器崩溃了，或者在“正确/错误”的时候调用了pg_stat_reset()或kin，这一点很容易解释。
页面原文内容由Stack Overflow提供。腾讯云小微IT领域专用引擎提供翻译支持
原文链接：
https://stackoverflow.com/questions/69619248
复制相关文章
相似问题
腾讯云开发者
