Horton

Re: relfilenode statistics

Michael Paquier <michael@paquier.xyz>

View thread
From: Michael Paquier <michael@paquier.xyz>
To: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
Cc: Kirill Reshke <reshkekirill@gmail.com>, Robert Haas <robertmhaas@gmail.com>, pgsql-hackers@lists.postgresql.org
Date: 2025-10-02T01:23:11Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Add more tests for relation statistics with rewrites

On Wed, Oct 01, 2025 at 02:33:11PM +0000, Bertrand Drouvot wrote:
> I think the first step is to replace (i.e get rid) PGSTAT_KIND_RELATION by a brand
> new PGSTAT_KIND_RELFILENODE and move all the existing stats that are currently
> under the PGSTAT_KIND_RELATION to this new PGSTAT_KIND_RELFILENODE.

Likely so, yes.

> Let's do this by keeping the pg_stat_all_tables|indexes and pg_statio_all_tables|indexes
> on top of the PGSTAT_KIND_RELFILENODE and ensure that a relation rewrite keeps 
> those stats. Once done, we could work from there to add new stats (add writes
> counters and ensure that some counters (n_dead_tup and friends) are replicated).

Do you think it is OK to define non-transactional pending stats as
being always a subset of the transactional stats?  I don't quite see 
if there would be a case to have stats that are only flushed in a
non-transactional path, while being discarded at the stats report done
at transaction commit time.  This means that it may be possible to
structure things so as the pending non-transaction stats structure are
always part of the transactional bits, and that the other way around
is not possible.  Perhaps that influences the design choices, at least
a bit.
--
Michael