Re: pg_stat_reset_single_*_counters vs pg_stat_database.stats_reset - Mailing list pgsql-hackers

From David G. Johnston
Subject Re: pg_stat_reset_single_*_counters vs pg_stat_database.stats_reset
Date
Msg-id CAKFQuwYyJMhCpt-Ok+hhhrv3xym2rUynK-py+iqH=nJNVo4dDQ@mail.gmail.com
Whole thread Raw
In response to Re: pg_stat_reset_single_*_counters vs pg_stat_database.stats_reset  (Andres Freund <andres@anarazel.de>)
Responses Re: pg_stat_reset_single_*_counters vs pg_stat_database.stats_reset  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
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.

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.


pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: [PATCH] Expose port->authn_id to extensions and triggers
Next
From: Peter Geoghegan
Date:
Subject: Re: [PATCH] Full support for index LP_DEAD hint bits on standby