From: | Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> |
---|---|
To: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | n_mod_since_analyze isn't reset at table truncation |
Date: | 2021-03-04 01:35:19 |
Message-ID: | CAD21AoAwdh5FqoVobm9qbQUR=tJjqnX8u5-d1RVFS1V=EexFMw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
While reviewing "autoanalyze on partitioned table" patch, I realized
that pg_stat_xxx_tables.n_mod_since_analyze is not reset at TRUNCATE.
On the other hand, n_ins_since_vacuum is reset. I think it should be
reset because otherwise we end up unnecessarily triggering autoanalyze
even when the actual number of newly inserted tuples is less than the
autoanalyze thresholds.
Steps to reproduce:
=# create table t (c int);
=# insert into t values (1), (2), (3);
=# update t set c = 999;
=# select relname, n_mod_since_analyze, n_ins_since_vacuum from
pg_stat_user_tables;
relname | n_mod_since_analyze | n_ins_since_vacuum
---------+---------------------+--------------------
t | 6 | 3
(1 row)
=# truncate t;
=# select relname, n_mod_since_analyze, n_ins_since_vacuum from
pg_stat_user_tables;
relname | n_mod_since_analyze | n_ins_since_vacuum
---------+---------------------+--------------------
t | 6 | 0
(1 row)
I've attached a small patch to fix this. Please review it.
Regards,
--
Masahiko Sawada
EDB: https://www.enterprisedb.com/
Attachment | Content-Type | Size |
---|---|---|
reset_n_mod_since_analyze.patch | application/octet-stream | 498 bytes |
From | Date | Subject | |
---|---|---|---|
Next Message | Tatsuo Ishii | 2021-03-04 01:42:36 | Re: PROXY protocol support |
Previous Message | Kyotaro Horiguchi | 2021-03-04 01:28:31 | Re: PITR promote bug: Checkpointer writes to older timeline |