Re: n_mod_since_analyze isn't reset at table truncation

On Thu, Mar 4, 2021 at 11:23 AM Julien Rouhaud <rjuju123(at)gmail(dot)com> wrote:
>
> On Thu, Mar 04, 2021 at 10:35:19AM +0900, Masahiko Sawada wrote:
> >
> > 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.
>
> Agreed.
>
> > I've attached a small patch to fix this. Please review it.
>
> The patch looks sensible to me, but the stats.sql (around l. 158) test should
> be modified to also check for effect on that field.

Thank you for looking at the patch!

Agreed. I've attached the updated patch.

I was going to add tests for both n_mod_since_analyze and
n_ins_since_analyze but it seems to require somewhat change pgstat
code to check n_ins_since_vacuum. Since n_ins_since_vacuum internally
uses the counter used also for n_tup_ins whose value isn't reset at
TRUNCATE, the values isn’t reset in some cases, for example, where a
table stats message for a new table has a truncation information
(i.g., tabmsg->t_counts.t_truncated is true). For example, even if we
add a check of n_ins_since_vacuum in stats.sql (at L158), the value is
not reset by running stats.sql regression test. So in this patch, I
added a check just for n_mod_since_analyze.

Regards,

--
Masahiko Sawada
EDB: https://www.enterprisedb.com/