On Thu, Mar 4, 2021 at 11:23 AM Julien Rouhaud <rjuju...@gmail.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/
reset_n_mod_since_analyze_v2.patch
Description: Binary data
