Date: Fri, 3 Jan 2025 16:18:37 +0000
From: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
To: Kirill Reshke <reshkekirill@gmail.com>
Cc: Robert Haas <robertmhaas@gmail.com>,
	Michael Paquier <michael@paquier.xyz>,
	pgsql-hackers@lists.postgresql.org
Subject: Re: relfilenode statistics
Message-ID: <Z3gN3bwUMijyV4I0@ip-10-97-1-34.eu-west-3.compute.internal>
References: <ZrBi9vNj5Ntyu62U@ip-10-97-1-34.eu-west-3.compute.internal>
 <Ztk4JIgWKk/8/dmd@ip-10-97-1-34.eu-west-3.compute.internal>
 <Zt/ZeIeWq0UVSAuy@ip-10-97-1-34.eu-west-3.compute.internal>
 <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>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <Z07d850Yp7Sd9Qqq@ip-10-97-1-34.eu-west-3.compute.internal>
Archived-At: <https://www.postgresql.org/message-id/Z3gN3bwUMijyV4I0%40ip-10-97-1-34.eu-west-3.compute.internal>
Precedence: bulk

Hi,

On Tue, Dec 03, 2024 at 10:31:15AM +0000, Bertrand Drouvot wrote:
> Hi,
> 
> On Fri, Nov 29, 2024 at 08:52:13PM +0500, Kirill Reshke wrote:
> > On Fri, 29 Nov 2024 at 20:20, Bertrand Drouvot
> > <bertranddrouvot.pg@gmail.com> wrote:
> > > On Fri, Nov 29, 2024 at 11:23:12AM +0500, Kirill Reshke wrote:
> > > > If we don’t have the relation OID when writing buffers out, can we
> > > > just store oid to buffertag mapping somewhere and use it?
> > >
> > > Do you mean add the relation OID into the BufferTag? While that could probably
> > > be done from a technical point of view (with probably non negligible amount
> > > of refactoring), I can see those cons:
> > 
> > Not exactly, what i had in mind was a separate hashmap into shared
> > memory, mapping buffertag<>oid.
> 
> I see.
> 
> > > 2. Probably lot of refactoring
> > > 3. This new member would be there "only" for stats and reporting purpose as
> > > it is not needed at all for buffer related operations
> > 
> > To this design, your points 2&3 apply.
> 
> That said, it might also help for DropRelationBuffers() where we need to scan
> the entire buffer pool (there is an optimization in place though). We could
> imagine buffertag as key and the value could be the relation OID and each entry
> would have next/prev pointers linking to other BufferTags with same OID.
> 
> That's probably much more refactoring (and more invasive) that the initial idea
> in this thread but could lead to multiple pros though. I'm not very familar with
> the "buffer" area of the code and would also need to study the performance impact
> to maintain this new hash map.
> 
> Do you and/or others have any thoughts/ideas about it?

As mentioned by Andres in [1], relying on the relation OID would not work to
"recover" the stats because we don't have access to the relation oid during crash
recovery. So, I'm going to resume working on the "initial" idea (i.e having the
stats keyed by relfilenode).

[1]: https://www.postgresql.org/message-id/xvetwjsnkhx2gp6np225g2h64f4mfmg6oopkuaiivrpzd2futj%40pflk55su36ho

Regards,

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