Re: n_mod_since_analyze isn't reset at table truncation

From: Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>
To: Julien Rouhaud <rjuju123(at)gmail(dot)com>
Cc: Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: n_mod_since_analyze isn't reset at table truncation
Date: 2021-03-05 04:50:24
Message-ID: CAD21AoDLJcBrEiErWp5KBJT2zQh1sW2TO35ARuBJTQxtAYv0CA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Mar 4, 2021 at 12:39 PM Julien Rouhaud <rjuju123(at)gmail(dot)com> wrote:
>
> On Thu, Mar 04, 2021 at 12:21:14PM +0900, Fujii Masao wrote:
> >
> >
> > On 2021/03/04 11:24, Julien Rouhaud 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.
> >
> > In that case, conversely, we want to trigger autoanalyze ASAP because the contents in the table was changed very much?
>
> We might want, but wouldn't keeping the current n_mod_since_analyze would make
> things unpredictable?

Right. I guess we should manually execute ANALYZE on the table to
refresh the statistics if we want to do that ASAP. It seems to me it
doesn't make any sense to trigger autoanalyze earlier than expected.

Regards,

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Kyotaro Horiguchi 2021-03-05 04:53:42 Re: 011_crash_recovery.pl intermittently fails
Previous Message Masahiko Sawada 2021-03-05 04:44:09 Re: n_mod_since_analyze isn't reset at table truncation