Re: Enhance statistics reset functions to return reset timestamp
От | Andres Freund |
---|---|
Тема | Re: Enhance statistics reset functions to return reset timestamp |
Дата | |
Msg-id | rjuapfdburuysftb277kvaytjttcljslbpqmeczn4len7afolr@d64ljacob3i5 обсуждение исходный текст |
Ответ на | Enhance statistics reset functions to return reset timestamp (Shinya Kato <shinya11.kato@gmail.com>) |
Ответы |
Re: Enhance statistics reset functions to return reset timestamp
|
Список | 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
В списке pgsql-hackers по дате отправления: