| 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 |
| 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 |