Re: n_mod_since_analyze isn't reset at table truncation

On 2021/03/04 12:40, Julien Rouhaud 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?

I don't think so. autoanalyze still works based on the number of
modifications since last analyze, so ISTM that's predictable...

> Also the selectivity estimation functions already take into account the actual
> relation size, so the estimates aren't completely off after a truncate.

But the statistics is out of date and which may affect the planning badly?
Also if generic plan is used, it's not updated until next analyze, i.e.,
generic plan created based on old statistics is used for a while.

So I'm still not sure why you want to defer autoanalyze in that case.

Regards,

--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION