Re: [Patch] New pg_stat_tablespace view

From: shihao zhong <zhong950419(at)gmail(dot)com>
To: Bernd Reiß <bd_reiss(at)gmx(dot)at>
Cc: Ahmed Gouda <ahmed(dot)gouda(at)cybertec(dot)at>, Zsolt Parragi <zsolt(dot)parragi(at)percona(dot)com>, songjinzhou <tsinghualucky912(at)foxmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, jian he <jian(dot)universality(at)gmail(dot)com>
Subject: Re: [Patch] New pg_stat_tablespace view
Date: 2026-09-19 03:07:07
Message-ID: CAGRkXqT0kE0cktzQALbzMrf_mHkfROPTJfCQvCYR02T9SAWt5A@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

Thanks,
Shihao

Attachment Content-Type Size
pg_stat_tablespace-v7.patch application/octet-stream 70.2 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Kirill Reshke 2026-09-19 04:52:44 Re: Wrong results from join removal with DISTINCT ON + SRF subquery
Previous Message Bruce Momjian 2026-09-19 02:02:44 Re: PG 19 status blog report