Re: pg_stat_reset_single_*_counters vs pg_stat_database.stats_reset
От | David G. Johnston |
---|---|
Тема | Re: pg_stat_reset_single_*_counters vs pg_stat_database.stats_reset |
Дата | |
Msg-id | CAKFQuwbujqk8L_Oqf=uM3eM+hKt0aRAXtA1AvyjeM1-CMEaYPA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: pg_stat_reset_single_*_counters vs pg_stat_database.stats_reset (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: pg_stat_reset_single_*_counters vs pg_stat_database.stats_reset
|
Список | pgsql-hackers |
On Tue, Mar 29, 2022 at 5:50 PM Andres Freund <andres@anarazel.de> wrote:
Hi,
On 2022-03-29 17:06:24 -0700, David G. Johnston wrote:
> On Tue, Mar 29, 2022 at 4:43 PM Andres Freund <andres@anarazel.de> wrote:
> > But more importantly, a
> > per-relation/function reset field wouldn't address Tomas's concern: He
> > wants a
> > single thing to check to see if any stats have been reset - and that's imo
> > a
> > quite reasonable desire.
> >
>
> Per the original email:
>
> "Starting with the below commit, pg_stat_reset_single_function_counters,
> pg_stat_reset_single_table_counters don't just reset the stats for the
> individual function, but also set pg_stat_database.stats_reset."
>
> Thus we already have the desired behavior, it is just poorly documented.
The problem is that it also make stats_reset useless for other purposes -
which I do consider a problem. Hence this thread. My concern would be
mollified if I there were a separate reset timestamp counting the last
"database wide" reset time. Your comment about that was something about
relation/function level timestamps, which doesn't seem relevant.
I can't figure out whether you agree that as of today stats_reset is the "database wide" reset time. The first sentence makes it sound like you do, the first one makes it sound like you don't.
David J.
В списке pgsql-hackers по дате отправления: