Re: Enhance statistics reset functions to return reset timestamp

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

In response to

Browse pgsql-hackers by date

  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