From: | Shinya Kato <shinya11(dot)kato(at)gmail(dot)com> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Enhance statistics reset functions to return reset timestamp |
Date: | 2025-09-12 06:31:52 |
Message-ID: | CAOzEurRtx83J7zQTs+-hEHDv_7N70CkBqxF49iBqswETOYugsg@mail.gmail.com |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
On Wed, Aug 13, 2025 at 4:06 PM Shinya Kato <shinya11(dot)kato(at)gmail(dot)com> wrote:
>
> On Sat, Aug 9, 2025 at 7:37 AM Andres Freund <andres(at)anarazel(dot)de> wrote:
> >
> > 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.
>
> As I mentioned earlier, the use case is to obtain an audit trail of
> the statistics reset time from the function’s return value.
>
> Also, how should we think about consistency with
> pg_stat_statements_reset()? The reset timestamp for pg_stat_statements
> can be obtained from the pg_stat_statements_info view, which returns a
> TIMESTAMPTZ. Of course, pg_stat_statements is a contrib module, so we
> don’t necessarily have to match its behavior. However, when running a
> script that resets various statistics before tests, if only
> pg_stat_statements_reset() returns a TIMESTAMPTZ, it might look as
> though the other statistics reset functions failed.
>
> What these patches do is simply return the TIMESTAMPTZ that is already
> computed for the pg_stat_* views, which seems to me a reasonable
> change.
Rebased the patches.
--
Best regards,
Shinya Kato
NTT OSS Center
Attachment | Content-Type | Size |
---|---|---|
v2-0001-Make-pg_stat_reset-return-the-reset-time.patch | application/octet-stream | 7.5 KB |
v2-0002-Make-pg_stat_reset_shared-return-the-reset-time.patch | application/octet-stream | 14.5 KB |
v2-0003-Make-pg_stat_reset_single_table_counters-return-t.patch | application/octet-stream | 6.3 KB |
v2-0004-Make-pg_stat_reset_backend_stats-return-the-reset.patch | application/octet-stream | 4.8 KB |
v2-0005-Make-pg_stat_reset_single_function_counters-retur.patch | application/octet-stream | 6.1 KB |
v2-0006-Make-pg_stat_reset_slru-return-the-reset-time.patch | application/octet-stream | 7.3 KB |
v2-0007-Make-pg_stat_reset_replication_slot-return-the-re.patch | application/octet-stream | 8.8 KB |
v2-0008-Make-pg_stat_reset_subscription_stats-return-the-.patch | application/octet-stream | 6.1 KB |
v2-0009-Make-pg_stat_clear_snapshot-return-the-reset-time.patch | application/octet-stream | 8.8 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2025-09-12 06:36:39 | Re: [PATCH] jit: fix build with LLVM-21 |
Previous Message | Zhang Mingli | 2025-09-12 06:09:47 | Re: Incremental View Maintenance, take 2 |