Re: [Patch] New pg_stat_tablespace view

Hi all,

On Mon, Sep 21, 2026 at 10:45 AM shihao zhong <zhong950419(at)gmail(dot)com> wrote:
>
> Hi Bernd,
>
> Thanks for testing.
>
> > blks_read differs exactly by 3 and blks_hit by 7
>
> I can reproduce this, and it does not need a restart. pg_stat_reset()
> clears the database entry and pg_stat_reset_shared() clears the tablespace
> entry. If more than a second passes between them, the backend flushes its
> pending counts in the gap, and the entry that was reset first keeps them.
> Swapping the two resets flips the sign. With both resets in one statement
> the numbers always match.
>
> > there is some skew in blk_read_time and blk_write_time
>
> Part of it was the second clock read. v7 reuses the time that
> pgstat_count_io_op_time() already computed.
>
>
> > one test still checks for >= 0
>
> Fixed.
>
> v7 attached.
>

Thank you for the updated patch. I tested the v7 patch and verified
that the regression suite completed successfully, with all 239 tests
passing, including the stats and tablespace tests. I also performed
targeted testing using a dedicated tablespace. The view reported
tuple activity for inserts, updates, and deletes, along with nonzero
block-write timing when I/O timing was enabled. The checkpoint
completed successfully, and the server log showed no errors in the
inspected output. After testing, I dropped the test table and
tablespace and shut down the separate test server cleanly. One concern
is that this targeted workload did not demonstrate nonzero
physical-read counters or read timing. Apart from this limitation, I
did not observe any functional or regression errors in the tests I
performed.

Regards,
Solai