Date: Tue, 30 Sep 2025 10:13:57 +0000
From: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
To: Michael Paquier <michael@paquier.xyz>
Cc: Kirill Reshke <reshkekirill@gmail.com>,
	Robert Haas <robertmhaas@gmail.com>,
	pgsql-hackers@lists.postgresql.org
Subject: Re: relfilenode statistics
Message-ID: <aNutZbziBycskOYR@ip-10-97-1-34.eu-west-3.compute.internal>
References: <ZyiTiqWPbRMseQjb@ip-10-97-1-34.eu-west-3.compute.internal>
 <CA+TgmoZtRxvAuMyO4bQjj5t47XWvQsowPAedkOkrCP61B7mQFg@mail.gmail.com>
 <Zym1xlMhuzPdekMt@ip-10-97-1-34.eu-west-3.compute.internal>
 <CALdSSPhQyvK_wsvV+HiQcC6f57Zg2WO60wxv=CXbcoZ1p5HHEQ@mail.gmail.com>
 <Z0nbomp2e/L30WDA@ip-10-97-1-34.eu-west-3.compute.internal>
 <CALdSSPhFaLEWXG9Mn8-tZoS68rE52647a2oZ6jrUNSBtwadD0A@mail.gmail.com>
 <Z07d850Yp7Sd9Qqq@ip-10-97-1-34.eu-west-3.compute.internal>
 <Z3gN3bwUMijyV4I0@ip-10-97-1-34.eu-west-3.compute.internal>
 <CALdSSPh76=ACN=z68oM44ZMgZsQxTTYVF8qvi1F6TGA5Mn6uiQ@mail.gmail.com>
 <aMkHSeitgUPtMyA2@paquier.xyz>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <aMkHSeitgUPtMyA2@paquier.xyz>
Archived-At: 
 <https://www.postgresql.org/message-id/aNutZbziBycskOYR%40ip-10-97-1-34.eu-west-3.compute.internal>
Precedence: bulk

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.gmail.com

Regards,

-- 
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com