Re: Should the docs have a warning about pg_stat_reset()? - Mailing list pgsql-hackers

From Jeff Janes
Subject Re: Should the docs have a warning about pg_stat_reset()?
Date
Msg-id CAMkU=1w+iFvTf=v-ZxCA3=Mk-L1tbbJwpLud2=ViNrL7C+HedQ@mail.gmail.com
Whole thread Raw
In response to Re: Should the docs have a warning about pg_stat_reset()?  (Bruce Momjian <bruce@momjian.us>)
List pgsql-hackers
On Wed, Apr 10, 2019 at 2:52 PM Bruce Momjian <bruce@momjian.us> wrote:

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?

When I've done it (not regularly, thankfully), it was usually because I failed to type "pg_stat_reset_shared('bgwriter')" or  "pg_stat_statements_reset()" correctly.

I've also been tempted to do it because storing snapshots with a cron job or something requires effort and planning ahead to set up the tables and cron and some way to limit the retention, and than running LAG windows functions over the snapshots requires a re-study of the documentation, because they are a bit esoteric and I don't use them enough to commit the syntax to memory.  I don't want to see pg_statio_user_indexes often enough to make elaborate arrangements ahead of time (especially since track_io_timing columns is missing from it); but when I do want them, I want them.  And when I do, I don't want them to be "since the beginning of time".

When I'm thinking about pg_statio_user_indexes, I am probably not thinking about autovac, since they have about nothing in common with each other.  (Other than pg_stat_reset operating on both.)

Cheers,

Jeff

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: hyrax vs. RelationBuildPartitionDesc
Next
From: Tom Lane
Date:
Subject: Re: COLLATE: Hash partition vs UPDATE