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
