Em qua, 10 de abr de 2019 às 16:33, Alvaro Herrera
<alvherre@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-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.
> >
> > 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
