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 1wP0pa-000LXH-1V for pgsql-hackers@arkaria.postgresql.org; Mon, 18 May 2026 16:28:38 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1wP0pX-002pUV-0D for pgsql-hackers@arkaria.postgresql.org; Mon, 18 May 2026 16:28:35 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1wP0pW-002pUN-0k for pgsql-hackers@lists.postgresql.org; Mon, 18 May 2026 16:28:35 +0000 Received: from mail-wm1-x32b.google.com ([2a00:1450:4864:20::32b]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1wP0pR-00000000CKM-20D8 for pgsql-hackers@lists.postgresql.org; Mon, 18 May 2026 16:28:34 +0000 Received: by mail-wm1-x32b.google.com with SMTP id 5b1f17b1804b1-488a9033b2cso19547515e9.2 for ; Mon, 18 May 2026 09:28:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1779121709; x=1779726509; darn=lists.postgresql.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=GozMhdcNV1Th1UbdH5MhbtzEAWV14RTB2HEvFO8/Foo=; b=jEa21DpsDR/ofU0Yv6TFI69YQGXUlQSd6GR2sYFTBKOdWXpgmkxGPqEg//SRtPu+mN 4ewVPyI02yCCdnVnHPlKzaY9qcuru4CkdEvzrWcykOsIYqgZu2rK4kYnAPpkAEIeaWU/ BH7OU9LPfRlD+zmXCgsNIwhCKE9QLDsi0tuPSWE0FOZkXbeGGbriLkbLj/eGSRszGSPs v6YjsfNR7b0QpY/QIvQizbG3pw36uUHrgusuw0TB3izivgykro9CTkPHYi4Taz7WR+e3 wx49t5n279uTR4pV/gshMYnMDQ7GAXLcrlwCnpbwxSunQC6aLDksJ5XIfze2bggnmUYL xCSg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779121709; x=1779726509; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=GozMhdcNV1Th1UbdH5MhbtzEAWV14RTB2HEvFO8/Foo=; b=RE8YPQusGv0bk81UzAhO5kVqciQRXYkF/mI54z0GGMNa7uZZW3/grtXfpHTJo2H/nl HZNs8xhbqIepzG7FCdbZreX6lAL9ZxlQv7TLU3vUH6l0dgXPvAsi2Ji19hlPOC8TDm9x yVw4NdEHmBUyEFzabP8wQ0Re6QQk4uKNq/iulhHBFrrXSTfA15H1G7VoXTn8euMjiZ7J E+wuqzsTSh2wbMg8064kNCY4CyG2Z6hCqoci5HR2ON49ISaDK2yQlrrsgYahT0BLtJY8 SRMRELsx3mNdDN2GHgKFMKJ1+j+y0gfkR9Dlv5cJRI7uTID5Jz8rNWmU29x2jbex9Q/n uQrg== X-Forwarded-Encrypted: i=1; AFNElJ+xxrmiW9OZzz5Zq1Qw69bd8GHlUd0D4rc9rKeIjbrpTt5H2iUIDKR3JemwsOJ2n4NkyFWsTiX1leoGCvnj@lists.postgresql.org X-Gm-Message-State: AOJu0Ywx6q8fbGYpHPfn8oStvKYEtgTrxLOz41GXj+PLlkyLoGwwD4v/ /E1iXk0OIqaJkADHbBfS7BMzLNgMec/NIfKyMSWXwJuAIq1XX16a0o00 X-Gm-Gg: Acq92OE8Eg3Hxh4zMPL2jsDkhQLXgMd1qI+359jLQo6sM3s8u39Rtpcpc1LqMEfeulP PjJxzI+2LFSVT1ew9y6ndFtYjRMIuRSXfpZem30syUBC7YXWAGfV6YdZHLXLRJrJl4833p/LArL VITsJpb9Rjl4o9WB2B66Y4wpBydmbZvwxWtdPbjKx1TmXCryJOncPxPN10md/UDwV8NYhwqAZ1e Ki9QzsJf7Q1NeWSmKsaGvFAlm4JcMl98rJwKJBVYnPXvImGVrjXXXZs1IqAPr1AXNt3mCP4wvK+ Yj2EwkyzXJQbF8Arm8SXc7CZjLKOPVwf+KB2BaU7AVRR69aKy+Og8DtYVfJhSe3dRIiQBw7e9k9 6fI7UYowV/guGA4nL1yT8R9HHCufB6QYGIgUXNUVq5m2WwRUA4IO70JIR+pZMk8A3D1Rt9CYRKN UUB1UOUaO9uhJcC5M48cIUCwKZOmmE9wwYEfqF2ZmUKieWQhwgQmBlMZerjHTs6MFRZbnpbDaXR aqaIrP++mY= X-Received: by 2002:a05:600c:350b:b0:48a:58ae:9938 with SMTP id 5b1f17b1804b1-48ff3346102mr172708535e9.19.1779121708546; Mon, 18 May 2026 09:28:28 -0700 (PDT) Received: from bdtpg (ec2-15-237-197-144.eu-west-3.compute.amazonaws.com. [15.237.197.144]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-48fe4c885d5sm243425305e9.5.2026.05.18.09.28.27 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 18 May 2026 09:28:27 -0700 (PDT) Date: Mon, 18 May 2026 16:28:26 +0000 From: Bertrand Drouvot To: Andres Freund , Michael Paquier Cc: Kirill Reshke , Robert Haas , pgsql-hackers@lists.postgresql.org Subject: Re: relfilenode statistics Message-ID: References: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="Uc+t0mng6H5VV2zk" Content-Disposition: inline In-Reply-To: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --Uc+t0mng6H5VV2zk Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, On Tue, Mar 31, 2026 at 10:45:50AM +0000, Bertrand Drouvot wrote: > Hi, > > On Wed, Mar 25, 2026 at 03:25:07AM +0000, Bertrand Drouvot wrote: > > Hi, > > > > On Wed, Mar 18, 2026 at 03:57:48AM +0000, Bertrand Drouvot wrote: > > > Hi, > > > > > > PFA, new rebase due to fba4233c832. > > > > Another rebase, due to 2102ebb1953 this time. > > It's more than probably too late for v19 but it needs another rebase due to > d7965d65fc5b this time. PFA v16, a rebase due to 775fe51daae, 71ff232a5bc and c0b53ec0630. While at it, let's sum up the current state: Regarding Michael's question [1] about whether we should copy stats across rewrites: I still believe we should. Not doing so would produce user-visible regressions. The complexity is contained in patch 0002 and the approach is tested (including 2PC, subtransaction abort, and rewrite chains). Regarding Michael's suggestion [2] to split PgStat_StatTabEntry into three kinds (table/index/relfilenode) from the start: I think this patch is the right incremental step that doesn't preclude a future split. Here's my reasoning: As Andres pointed out [3], we'd want to populate more than just dead_tuples/ins_since_vacuum/mod_since_analyze during recovery. The right boundary for a split isn't clear yet until we actually implement WAL-replay-based stat population. I think that splitting now would be a much larger change with the risk of drawing the boundaries wrong. The current approach (key PGSTAT_KIND_RELATION by locator, keep the unified structure) is a contained change that unblocks future work. Once we have WAL replay populating stats, we'll have a much better understanding of what a split should look like, if one is still needed. I think we should do this incremental step first, then split later if/when the need becomes clearer. I believe we have consensus on the core approach ("use the relfilenumber instead of the relation OID, without changing the user experience"). The implementation addresses all the technical concerns raised so far (no new hash key field, PSEUDO_PARTITION_TABLE_SPCOID for partitioned tables, pgstat_fetch_stat_tabentry_by_locator() to avoid extra syscache lookups in do_autovacuum()). Andres, would you be willing to drive this toward commit once we've iterated on any remaining review feedback? Michael, I understand this isn't the design you'd prefer. Would you be open to reviewing the implementation nonetheless, or do you have a hard objection that would block this path? I'm happy to address any further concerns. [1]: https://postgr.es/m/aRGoGcOdutTHQfpn%40paquier.xyz [2]: https://postgr.es/m/aUELPdhdcyzTM_8K%40paquier.xyz [3]: https://postgr.es/m/zferux2jlbhqymubzhpubfrkjzhzxzguq4eprtycojtif5vbqh%402t7cu2teyqmi Regards, -- Bertrand Drouvot PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services: https://aws.amazon.com --Uc+t0mng6H5VV2zk Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="v16-0001-Key-PGSTAT_KIND_RELATION-by-relfile-locator.patch"