On Sat, 30 Mar 2019 at 00:59, Robert Haas <robertmhaas@gmail.com> wrote:
>
> 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 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-1J7phkw@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