Re: [Patch] New pg_stat_tablespace view - Mailing list pgsql-hackers

From shihao zhong
Subject Re: [Patch] New pg_stat_tablespace view
Date
Msg-id CAGRkXqT6dLa4H1ZbR_Tf6zMWA+Kwi8_v-mncYMvHDo1YCd76hA@mail.gmail.com
Whole thread
In response to Re: [Patch] New pg_stat_tablespace view  (Zsolt Parragi <zsolt.parragi@percona.com>)
Responses Re: [Patch] New pg_stat_tablespace view
List pgsql-hackers
On Tue, Mar 24, 2026 at 6:11 PM Zsolt Parragi <zsolt.parragi@percona.com> wrote:
>
> Hello!
>
> blk_read_time and blk_write_time doesn't seem to work, they show 0 to
> me even after some workloads, and I don't see any assignments in the
> code. The testcase also checks for "blk_read_time >= 0" which
> trivially succeeds.
>
> blocks_fetched is also misleading, it includes both reads and cache
> hits. pg_stat_database calls this column blocks_read, and properly
> substracts blocks_hit from it.
>
> + rel->pgstat_info->reltablespace = rel->rd_locator.spcOid;
>
> Shouldn't this be included in TwoPhasePgStatRecord / pgstat_twophase_postcommit?
>
>

Hi Zsolt and Jian,

Thanks for the feedback. I've attached v3, addressing all comments.
Notably, I've included tuple-level stats in the pg_stat_tablespace
view to align with the addition of SpaceOid in TwoPhasePgStatRecord.

Thanks,
Shihao

Attachment

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Update documentation for SET to include SCHEMA / NAMES syntax
Next
From: Dmitry Dolgov
Date:
Subject: Re: pg_buffercache: Add per-relation summary stats