On Tue, Mar 24, 2026 at 3:22 AM songjinzhou <[email protected]> wrote: > > 在 2026/3/24 10:49, shihao zhong 写道: > > On Mon, Mar 23, 2026 at 3:08 PM shihao zhong <[email protected]> wrote: > >> > >> 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 > > > > 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 Hi SongJin,
Thanks for your reviewing, the v2 patch addresses both 1 and 2. Thanks, Shihao
pg_stat_tablespace_final_v2.patch
Description: Binary data
