Re: Should the docs have a warning about pg_stat_reset()?

Поиск
Список
Период
Сортировка
От Jeff Janes
Тема Re: Should the docs have a warning about pg_stat_reset()?
Дата
Msg-id CAMkU=1w+iFvTf=v-ZxCA3=Mk-L1tbbJwpLud2=ViNrL7C+HedQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Should the docs have a warning about pg_stat_reset()?  (Bruce Momjian <bruce@momjian.us>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: hyrax vs. RelationBuildPartitionDesc
Следующее
От: Tom Lane
Дата:
Сообщение: Re: COLLATE: Hash partition vs UPDATE