| From: | Julien Rouhaud <rjuju123(at)gmail(dot)com> |
|---|---|
| To: | Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com> |
| Cc: | Masahiko Sawada <sawada(dot)mshk(at)gmail(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-04 03:40:17 |
| Message-ID: | 20210304034017.kzs2vhah3kenk2vy@nol |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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?
Also the selectivity estimation functions already take into account the actual
relation size, so the estimates aren't completely off after a truncate.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | houzj.fnst@fujitsu.com | 2021-03-04 03:41:39 | RE: Avoid CommandCounterIncrement in RI trigger when INSERT INTO referencing table |
| Previous Message | houzj.fnst@fujitsu.com | 2021-03-04 03:39:25 | RE: Avoid CommandCounterIncrement in RI trigger when INSERT INTO referencing table |