Subject: [Patch] New pg_stat_tablespace view

From: shihao zhong <[email-masked]>
Date: Mon, 23 Mar 2026 15:08:52 -0400

Hi hackers,

I’ve been working on extending the cumulative statistics system to
provide better visibility into tablespace-level workloads, and I'd
like to propose a patch to add a new system view: pg_stat_tablespace.

Currently, PostgreSQL provides statistics per database (e.g.,
pg_stat_database) and per relation (e.g., pg_statio_user_tables).
However, because tablespaces can span multiple databases, it is
difficult for DBAs to analyze storage hotspots across the cluster or
verify if a specific tablespace (such as a high-performance SSD vs a
slow HDD array) is experiencing I/O bottlenecks or excessive temporary
file usage.

The pg_stat_tablespace view bridges this gap by providing an aggregate
view of block I/O and temporary file usage grouped by tablespace,
making it easier to optimize storage architectures.

Thanks,
Shihao

---

From: shihao zhong <[email-masked]>
Date: Mon, 23 Mar 2026 22:49:41 -0400

> making it easier to optimize storage architectures.

New version fix the CI/CD

---

From: Zsolt Parragi <[email-masked]>
Date: Tue, 24 Mar 2026 06:12:01 +0000

Hello!

I get assertion failures with the patch, all it takes is a simple select:

SELECT * FROM pg_stat_tablespace;
  TRAP: failed Assert("tupdesc->firstNonCachedOffsetAttr >= 0"),
  File: execTuples.c, Line: 2341

The test suite also fails with similar errors.

---

From: songjinzhou <[email-masked]>
Date: Tue, 24 Mar 2026 15:22:29 +0800

> New version fix the CI/CD

Hello, shihao

I applied it on master and did a simple test. Here are some minor review 
comments:

1. The type of temp_bytes in monitoring.sgml should be bigint, but it 
was written as numeric here.

2. The pgstat_drop_tablespace function doesn't seem to be called.

Thank you.

-- 
regards,
songjinzhou

---

From: shihao zhong <[email-masked]>
Date: Tue, 24 Mar 2026 13:29:48 -0400

> 2. The pgstat_drop_tablespace function doesn't seem to be called.
Hi SongJin,

Thanks for your reviewing, the v2 patch addresses both 1 and 2.

Thanks,
Shihao

---

From: Zsolt Parragi <[email-masked]>
Date: Tue, 24 Mar 2026 22:11:01 +0000

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?

---

From: shihao zhong <[email-masked]>
Date: Fri, 27 Mar 2026 14:05:22 -0400

> 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

---

From: shihao zhong <[email-masked]>
Date: Wed, 1 Apr 2026 21:54:25 -0400

> view to align with the addition of SpaceOid in TwoPhasePgStatRecord.

Rebase with head.