Re: Should the docs have a warning about pg_stat_reset()?

On Wed, Mar 27, 2019 at 7:49 PM David Rowley
<david.rowley@2ndquadrant.com> wrote:
> Yeah, analyze, not vacuum.  It is a bit scary to add new ways for
> auto-vacuum to suddenly have a lot of work to do.  When all workers
> are busy it can lead to neglect of other duties.  It's true that there
> won't be much in the way of routine vacuuming work for the database
> the stats were just reset on, as of course, all the n_dead_tup
> counters were just reset. However, it could starve other databases of
> vacuum attention.  Anti-wraparound vacuums on the current database may
> get neglected too.
>
> I'm not saying let's not do it, I'm just saying we need to think of
> what bad things could happen as a result of such a change.

+1.  I think that if we documented that pg_stat_reset() is going to
trigger an auto-analyze of every table in your system, we'd have some
people who didn't read the documentation and unleashed a storm of
auto-analyze activity, and other people who did read the documentation
and then intentionally used it to unleash a storm of auto-analyze
activity.  Neither sounds that great.

I really wish somebody had the time and energy to put some serious
work on the problem of autovacuum scheduling in general.  Our current
algorithm is a huge improvement over what what we had before 8.3, but
that was a decade ago.  This particular issue strikes me as something
that is likely to be hard to solve with an isolated tweak.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company