Re: [Patch] New pg_stat_tablespace view

From: Bernd Reiß <bd_reiss(at)gmx(dot)at>
To: shihao zhong <zhong950419(at)gmail(dot)com>
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-24 17:33:59
Message-ID: fbf06ac2-15ce-412a-92de-f533d2f9774d@gmx.at
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi Shihao,

On 19/09/2026 05:07, shihao zhong 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.
>

Yes, this explains it.

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

I like this: Having the test being strictly bigger and comparing to
beforehand values makes much sense to me.

> v7 attached.
>
> Thanks,
> Shihao
>
>
>

Best
Bernd

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Zsolt Parragi 2026-09-24 17:35:09 Re: Unlogged materialized views
Previous Message Jacob Champion 2026-09-24 17:30:45 Re: [PATCH] Add a check_hook for output_plugin_libraries