Em qua, 10 de abr de 2019 às 16:33, Alvaro Herrera <alvhe...@2ndquadrant.com> escreveu: > > On 2019-Apr-10, Bruce Momjian wrote: > > > On Thu, Apr 11, 2019 at 04:14:11AM +1200, David Rowley wrote: > > > > 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. > > > > OK, let me step back. Why are people resetting the statistics > > regularly? Based on that purpose, does it make sense to clear the > > stats that effect autovacuum? > > I agree that we should research that angle. IMO resetting stats should > be seriously frowned upon. And if they do need to reset some counters > for some valid reason, offer a mechanism that leaves the autovac- > guiding counters alone. > Then you have to change the way pg_stat_reset() works (it currently removes the hash tables). Even pg_stat_reset_single_table_counters() could cause trouble although it is in a smaller proportion. Reset statistics leaves autovacuum state machine in an invalid state. Since reset statistic is a rare situation (at least I don't know monitoring tools or practices that regularly execute those functions), would it be worth adding complexity to pg_stat_reset* functions? autovacuum could handle those rare cases just fine.
> IMO the answer for $SUBJECT is yes. > +1. However, I also suggest a WARNING saying "autovacuum won't work because you reset statistics that it depends on" plus detail "Consider executing ANALYZE on all your tables" / "Consider executing ANALYZE on table foo.bar". -- Euler Taveira Timbira - http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
