Hi,
On Mon, Oct 06, 2025 at 03:37:18PM +0900, Michael Paquier wrote:
> On Mon, Oct 06, 2025 at 03:33:41PM +0900, Michael Paquier wrote:
> > And applied this one as well after a few tweaks, mainly consistency in
> > the code, with what should be the proper format bumps (thanks for the
> > notes in your proposed commit message).
Thanks!
>
> And I forgot to mention something: now the only stats kind that does
> not have a reset timestamp callback but has a SQL function able to do
> resets is PGSTAT_KIND_FUNCTION.
Checking for other stats kinds would have been my next step, step for doing it!
> Is it worth caring about doing
> something for this case as well?
I think so as I don't see any reasons not to do so.
PFA a patch to add stats_reset to pg_stat_user_functions.
A few remakrs:
- It does not use an existing macro (as such macro does not exist) to generate the
function that reports this new field. So we've more flexibility for the name
and went for pg_stat_get_function_stat_reset_time() (to be consistent with
say pg_stat_get_db_stat_reset_time()).
- The tests are done in the isolation suite (as this is where
pg_stat_reset_single_function_counters() is already being tested) and I don't
think there is a need to add one in the regress suite (that test for the
pg_stat_user_functions output). Indeed the pg_stat_get_function_stat_reset_time()
call output test is already added in the isolation one.
- The new field is not added in pg_stat_xact_user_functions for the exact
same reasons as it was not added for the relations case.
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
