public inbox for [email protected]
help / color / mirror / Atom feedFrom: Bertrand Drouvot <[email protected]>
To: Michael Paquier <[email protected]>
Cc: Kirill Reshke <[email protected]>
Cc: Robert Haas <[email protected]>
Cc: [email protected]
Subject: Re: relfilenode statistics
Date: Tue, 30 Sep 2025 10:13:57 +0000
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
<CA+TgmoZtRxvAuMyO4bQjj5t47XWvQsowPAedkOkrCP61B7mQFg@mail.gmail.com>
<[email protected]>
<CALdSSPhQyvK_wsvV+HiQcC6f57Zg2WO60wxv=CXbcoZ1p5HHEQ@mail.gmail.com>
<Z0nbomp2e/[email protected]>
<CALdSSPhFaLEWXG9Mn8-tZoS68rE52647a2oZ6jrUNSBtwadD0A@mail.gmail.com>
<[email protected]>
<[email protected]>
<CALdSSPh76=ACN=z68oM44ZMgZsQxTTYVF8qvi1F6TGA5Mn6uiQ@mail.gmail.com>
<[email protected]>
Hi,
On Tue, Sep 16, 2025 at 03:44:25PM +0900, Michael Paquier wrote:
> 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.
+1.
> 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.
Right. I'll come back with a rebase, and a POC proposal on some stats so that
we could agree on the design. Also, it looks like that we have a consensus on
"sometimes I don't know the relation OID so I want to use the relfilenumber instead,
without changing the user experience" (see [1)).
As far Michael's concern about adding a new field in the hash key, as 8 bytes
is allocated for the object ID, then we can go with:
dboid (linked to RelFileLocator's dbOid)
objoid (linked to RelFileLocator's spcOid and to the RelFileLocator's relNumber)
and avoid adding a new field in the key.
[1]: https://www.postgresql.org/message-id/CA%2BTgmoZ0u6ek_xxYJaGVBk0uEvH5txoYsCwbvxKWe-2xn_G_qg%40mail.g...
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: relfilenode statistics
In-Reply-To: <[email protected]>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox