Re: relfilenode statistics - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: relfilenode statistics
Date
Msg-id aMkHSeitgUPtMyA2@paquier.xyz
Whole thread Raw
In response to Re: relfilenode statistics  (Kirill Reshke <reshkekirill@gmail.com>)
List pgsql-hackers
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

Attachment

pgsql-hackers by date:

Previous
From: shveta malik
Date:
Subject: Re: Improve pg_sync_replication_slots() to wait for primary to advance
Next
From: John Naylor
Date:
Subject: Re: [PATCH] Refactor bytea_sortsupport(), take two