On Sat, 30 Mar 2019 at 00:59, Robert Haas <robertmh...@gmail.com> wrote: > > 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 still think we should start with a warning about pg_stat_reset(). People are surprised by this, and these are just the ones who notice: https://www.postgresql.org/message-id/CAB_myF4sZpxNXdb-x=welpqbdou6ue8fhtm0fverpm-1j7p...@mail.gmail.com I imagine there are many others just suffering from bloat due to auto-vacuum not knowing how many dead tuples there are in the tables. -- David Rowley http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
