Re: relfilenode statistics

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Kirill Reshke <reshkekirill(at)gmail(dot)com>
Cc: Bertrand Drouvot <bertranddrouvot(dot)pg(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: relfilenode statistics
Date: 2025-09-16 06:44:25
Message-ID: aMkHSeitgUPtMyA2@paquier.xyz
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: 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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message John Naylor 2025-09-16 06:46:55 Re: [PATCH] Refactor bytea_sortsupport(), take two
Previous Message shveta malik 2025-09-16 06:23:36 Re: Improve pg_sync_replication_slots() to wait for primary to advance