n_mod_since_analyze isn't reset at table truncation

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

Responses

Browse pgsql-hackers by date

  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