On Wed, Mar 27, 2019 at 7:49 PM David Rowley <david.row...@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