From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
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 08:06:16 |
Message-ID: | aJWv-BsxOUsxAIHc@paquier.xyz |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Aug 08, 2025 at 01:18:39PM +0900, Shinya Kato wrote:
> 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()
>
> For pg_stat_reset_backend_stats() and
> pg_stat_reset_replication_slot(), the functions return the reset
> timestamp when a valid input is provided. If an invalid input is given
> (e.g., an invalid backend PID or replication slot name), the functions
> return NULL.
> This allows users to easily determine whether the reset operation was
> successful based on the return value.
I am not sure that this is a good idea overall, but I'm OK if I finish
outvoted.
At the exception of pg_stat_reset_backend_stats(), all the functions
you are listing above are written so as they never fail, so claiming
that returning a timestamp value for this reason sounds a bit strange
to me. And we already know this information based on what the stats
tables already hold for the reset timestamps set when their stats
kinds callbacks are called.
I can get behind a change for pg_stat_reset_backend_stats() to make it
return a status, though, as the information depends on some procnum
lookups which is triggered depending on what the user provides in
input.
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Smith | 2025-08-08 08:08:27 | Re: [WIP]Vertical Clustered Index (columnar store extension) - take2 |
Previous Message | Michael Paquier | 2025-08-08 07:51:45 | Re: Support for 8-byte TOAST values (aka the TOAST infinite loop problem) |