From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Shinya Kato <shinya11(dot)kato(at)gmail(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Enhance statistics reset functions to return reset timestamp |
Date: | 2025-08-08 22:37:51 |
Message-ID: | rjuapfdburuysftb277kvaytjttcljslbpqmeczn4len7afolr@d64ljacob3i5 |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
On 2025-08-08 13:18:39 +0900, Shinya Kato wrote:
> I would like to propose a series of patches that enhance the behavior
> of various statistics reset functions by making them return the reset
> timestamp. This change improves usability and aligns with the behavior
> introduced in commit dc9f8a798[1], where pg_stat_statements_reset()
> was updated to return the reset time.
>
> The following functions have been modified to return a TIMESTAMP WITH
> TIME ZONE value indicating when the statistics were reset:
> - pg_stat_reset()
> - pg_stat_reset_shared()
> - pg_stat_reset_single_table_counters()
> - pg_stat_reset_backend_stats()
> - pg_stat_reset_single_function_counters()
> - pg_stat_reset_slru()
> - pg_stat_reset_replication_slot()
> - pg_stat_reset_subscription_stats()
> - pg_stat_clear_snapshot()
-1 - I think it was a mistake to introduce support for granular resets, we
shouldn't bury ourselves deeper. If anything we should rip out everything
other than 1) a global reset b) a per-database reset.
Leaving that aside, I just don't see a convincing use case for returning the
timestamp here.
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | Dagfinn Ilmari Mannsåker | 2025-08-08 22:55:33 | Re: Improve tab completion for various SET/RESET forms |
Previous Message | Jacob Champion | 2025-08-08 22:37:42 | Re: Support getrandom() for pg_strong_random() source |