Re: relfilenode statistics

Michael Paquier <michael@paquier.xyz>

From: Michael Paquier <michael@paquier.xyz>

To: Kirill Reshke <reshkekirill@gmail.com>

Cc: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>, Robert Haas <robertmhaas@gmail.com>, pgsql-hackers@lists.postgresql.org

Date: 2025-09-16T06:44:25Z

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 →

Add more tests for relation statistics with rewrites
- b23fe993e136 19 (unreleased) landed

On Thu, Mar 13, 2025 at 02:00:52PM +0500, Kirill Reshke wrote:
> Hmm. While it is true that catalog lookups cannot be performed during
> crash recovery, is it really necessary to save and retrieve statistics
> after a crash?

Yes, losing stats on crash is a *very* annoying thing.  Having no
stats for a relation means that autovacuum gives up entirely on
relations it has no stats of, skipping it entirely until they have
rebuilt and bloat would accumulate.  Being able to recover these stats 
from crash recovery is a cheap design, that would improve reliability
by a large degree.

> Given that statistics are permitted to be outdated and
> server crashes are anticipated to be infrequent, it looks loke losing
> a few analysis runs due to server crashes is acceptable.
> In any case, I am totally OK with the relfilenode-based method because
> it is generally less restricted (to other postgresql parts e.g. wal-
> replay ) and simpler.

The startup process is not connected to a database and has no access
to pg_class: the only thing we can know about are the on-disk files,
not their in-catalog OIDs.  FWIW, I think that this patch would be a
huge step forward a more reliable stats system.

True that the patch needs a rebase.  Bertrand has also mentioned that
some points needed more work.
--
Michael