Re: pg_stat_reset_single_*_counters vs pg_stat_database.stats_reset

On Tue, Mar 29, 2022 at 4:43 PM Andres Freund <andres(at)anarazel(dot)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.

Now, maybe other functions aren't doing this? If so, given these functions
do, we probably should just change any outliers to match.

I'm reading Tomas's comments as basically a defense of the status quo, at
least so far as the field goes. He didn't comment on the idea of "drop the
reset_[relation|function]_counters(...)" functions. Combined, I take that
as supporting the entire status quo: leaving the function and fields
as-is. I'm inclined to do the same. I don't see any real benefit to
change here as there is no user demand for it and the field change proposal
is to change only one of the at least three locations that should be
changed if we want to have a consistent design. And we aren't getting user
reports saying the presence of the functions is a problem (confusion or
otherwise) either, so unless there is a technical reason writing these
functions in the new system is undesirable we have no justification that I
can see for removing the long-standing feature.

David J.