Re: Add stats_reset to pg_stat_all_tables|indexes and related views

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Bertrand Drouvot <bertranddrouvot(dot)pg(at)gmail(dot)com>
Cc: Sami Imseih <samimseih(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Add stats_reset to pg_stat_all_tables|indexes and related views
Date: 2025-10-08 03:54:18
Message-ID: aOXgaqGzoD_dMx_y@paquier.xyz
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Oct 07, 2025 at 08:21:16AM +0000, Bertrand Drouvot wrote:
> stats are reset only for s1, but that does not hurt to check that s2 also
> provides expected results: done in the attached. Also re-tested CATCACHE_FORCE_RELEASE
> and RELCACHE_FORCE_RELEASE with this new test.

One thing which was looking annoying, with fresh eyes, is the fact
that querying stats_reset in each query that wants to retrieve the
function stats leads to 1.2k lines of additional diffs. However, only
one permutation uses the reset function. So at the end, I have added
a new step that queries pg_stat_get_function_stat_reset_time(), and
used it in the only permutation that does a reset of the counters.
This move leads to 20 lines of additional output for each output file,
which is more tolerable. Applied with this tweak, and bumps with the
mandatory bumps for the catalog version and PGSTAT_FILE_FORMAT_ID.

>> Of course. reset_stats is a state stored in shmem, we don't need it
>> in the transaction views that only get what's local to the
>> transaction. Perhaps I should have kept the note in a5b543258aa2
>> about the table/index stats, but that did not strike me as worth
>> mentioning based on how the xact views are implemented.
>
> Yeah. Maybe add a word or two in this commit if you really feel the
> need. I just mentioned it in the thread for reference anyway.

This did not feel absolutely mandatory, so I have left this part out
of the commit message.

We should be done here, then.
--
Michael

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message David Rowley 2025-10-08 04:02:39 Re: Should we update the random_page_cost default value?
Previous Message Dilip Kumar 2025-10-08 03:43:21 Re: Logical Replication of sequences