Date: Thu, 13 Aug 2026 08:09:25 +0000
From: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
To: Michael Paquier <michael@paquier.xyz>
Cc: Andres Freund <andres@anarazel.de>,
	Kirill Reshke <reshkekirill@gmail.com>,
	Robert Haas <robertmhaas@gmail.com>,
	pgsql-hackers@lists.postgresql.org
Subject: Re: relfilenode statistics
Message-ID: <an17tXR24VxWE3w4@bdtpg>
References: <aRGoGcOdutTHQfpn@paquier.xyz>
 <aRS9+yaGhjDslRWj@ip-10-97-1-34.eu-west-3.compute.internal>
 <aUA3XkU9hc1xrtRB@ip-10-97-1-34.eu-west-3.compute.internal>
 <ezbfcpjtfh3vtm667aegyrptcdsvinbuxw6y5p6j3e5fbffrl5@i7v6cjapz3yv>
 <aUELPdhdcyzTM_8K@paquier.xyz>
 <zferux2jlbhqymubzhpubfrkjzhzxzguq4eprtycojtif5vbqh@2t7cu2teyqmi>
 <aWYQXiKgIIvrlyVi@ip-10-97-1-34.eu-west-3.compute.internal>
 <aZv2B8CFJZTKEl8j@ip-10-97-1-34.eu-west-3.compute.internal>
 <aa56L2wM16VldK5f@ip-10-97-1-34.eu-west-3.compute.internal>
 <alCLr8ya-4ojew-x@paquier.xyz>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <alCLr8ya-4ojew-x@paquier.xyz>
Archived-At: <https://www.postgresql.org/message-id/an17tXR24VxWE3w4%40bdtpg>
Precedence: bulk

Hi,

On Fri, Jul 10, 2026 at 03:05:35PM +0900, Michael Paquier wrote:
> - 0003

Thanks for sharing this! Now that the table/index split is (almost) in, let's
focus again on the relfilenode statistics.

> property that I do not wish to keep around is the aggregation of
> counters across rewrites, as the new counters don't make sense once we
> switch to a new relfilenode.

I think we should first agree on this point before looking further at 0003.
As written, the existing pg_stat_all_tables tuple related counters would be reset
by a rewrite.

The concern I see is how these statistics are currently used: relation_needs_vacanalyze()
uses dead_tuples, ins_since_vacuum, and mod_since_analyze for its three tuple based
vacuum or analyze decisions.

For example, a SET TABLESPACE move allocates a new relfilenumber but only copies
the relation’s storage. The previous counters are not transferred, so they are
read as zero for the new relfilenumber. A table that was eligible for vacuum or
analyze before the move may therefore no longer be eligible.

Do you agree that rewrites should not reset these counters?

Regards,

-- 
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com