Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1w4w6G-002iHq-2v for pgsql-hackers@arkaria.postgresql.org; Tue, 24 Mar 2026 07:22:53 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1w4w6F-0056kJ-0p for pgsql-hackers@arkaria.postgresql.org; Tue, 24 Mar 2026 07:22:51 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with utf8esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1w4w6E-0056k8-05 for pgsql-hackers@lists.postgresql.org; Tue, 24 Mar 2026 07:22:51 +0000 Received: from out162-62-57-87.mail.qq.com ([162.62.57.87]) by makus.postgresql.org with utf8esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1w4w69-00000000koU-2PSj for pgsql-hackers@postgresql.org; Tue, 24 Mar 2026 07:22:49 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=foxmail.com; s=s201512; t=1774336950; bh=d4C+SRj0/wwzwDSUfrbLR8VwKfvjQiBSOiXxY5HGfWY=; h=Date:Subject:To:References:From:In-Reply-To; b=o4JpGPmmvFpb8U3U5txCtjjLETuLyG3av2CW36qbKMiwUxNAzisPKOiOJv5ot2VFG BOEu17hbkRM8arRJVRcdOEZfBXxFGKs9cqrBQaaB/qQ9H98bHF6aX/Wvw7hYq0jqxC UJItZLIYjA/RuUFbdd30lez2uL8Y9Q7N+bgyLyhQ= Received: from [192.168.1.4] ([111.18.139.47]) by newxmesmtplogicsvrszb51-1.qq.com (NewEsmtp) with SMTP id 59C8FAD2; Tue, 24 Mar 2026 15:22:28 +0800 X-QQ-mid: xmsmtpt1774336948t8816o3e7 Message-ID: X-QQ-XMAILINFO: MyIXMys/8kCt35UabUz/QXd09IgME16WaStKJxzEyW9G8mLQMbm3qshqHcWYWE 7L8l2BvBjmSsxbPL57ZaAfhI1m2hEztipem0LX4jfAiUgbMaNHhR+ITFmU7pfCJobVh9HWlCRg/X ZnEm/meHmt2oRAdDVT3MM5B1u8Nl5h1SQGZKkbzJ9Fs8nkhz+N/sHNJnaqw3j9gIhIx1fPvJId0s HOWppRevRoFAiwznEu+adppji7LnRQhlIumXWuWZhWxGTNVgVzoJ/gKLsfiaZsJJhdHWAP4NME73 ykWNLLn09a6RuYYkPbofJX/VD0Ztz/RRlaNMk5HmCux62+MLhAkCZ1J87IRlGwtENtO9c6+qh8D2 2pzb7wdBHEFVdCxlx1EaBav1yw7bCQj09EuRcKKOrLbUyWt6dFt4pRFV2IgfNkXklcROwMsBhKl3 Z6c1zcQWkWEiVIwwv4lxnMatzKbKn1mwrN0Y4Jtg2gecXxuak1QHTQ2VzudVrfwlU3hHR/qugiwr N+C9La+w7wbadJsyFr3lF6SFPlHhVTxNG9wnyJ/+4YsqNUSBKxKNtSqwqDQ0bdec/FoPlJf7wAvZ XTJa5fcY9WH+sTNqMNRNgJgONkLwQr/rxljsjrqmGWHiAberYjcRrXZcX77Cd4lS++AxcLb02su9 4Fn6twEkz6wFb/cC6aYWxkTrzwbkWdZehxGeUUqP/g5GWz/DX0Mygw5qwbnxbzdkOEzQxhHbLtlW jmO+GfQ3c9njY99K4AiFzkhjDm0d1dRxV9QbGCyrxuOXL2kyxk+Rd7/SgLZVB4dNQbjKtOU+oifx 4lFElPplkrWXjGCZYgMArc35XsLsIBSDyUs0jBj4Kq7Gxz/cTkVmXZyQ+HJ4/H4ySq8sTG5Ml0/7 PhdzByvucklfaRhpqrPLfQrmCc5xzWRcteSUeZy8NEODXLCAORImyLzYJ/lA//u7QV11g3QVPpyu L/ZFYv/N0a9ZeJryQDuU182g+PbYWSPK1jSJ4joBMoolf3hbFSZ+ZEu6jw554ie7lmee+S4H+IiS ra28JorP4HOHYaRfeaRj2qbhB0az5alvxdmCrSFMwCDaOAfFLzsDsMEpAFZ2i+IEuXuMlk9A== X-QQ-XMRINFO: Mp0Kj//9VHAxzKrPej0RrxKruWtDXEn4Jw== X-OQ-MSGID: Date: Tue, 24 Mar 2026 15:22:29 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [Patch] New pg_stat_tablespace view To: shihao zhong , PostgreSQL-development References: From: songjinzhou In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk 在 2026/3/24 10:49, shihao zhong 写道: > On Mon, Mar 23, 2026 at 3:08 PM shihao zhong 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