Date: Fri, 29 Nov 2024 15:20:02 +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: <Z0nbomp2e/L30WDA@ip-10-97-1-34.eu-west-3.compute.internal>
References: <Zo6OvsBLUbYm6nQM@ip-10-97-1-34.eu-west-3.compute.internal>
 <Zo9j69GhexDpeV4k@paquier.xyz>
 <Zo93T63yVkDcKw3P@ip-10-97-1-34.eu-west-3.compute.internal>
 <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>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CALdSSPhQyvK_wsvV+HiQcC6f57Zg2WO60wxv=CXbcoZ1p5HHEQ@mail.gmail.com>
Archived-At: <https://www.postgresql.org/message-id/Z0nbomp2e/L30WDA%40ip-10-97-1-34.eu-west-3.compute.internal>
Precedence: bulk

Hi,

On Fri, Nov 29, 2024 at 11:23:12AM +0500, Kirill Reshke wrote:
> On Tue, 5 Nov 2024 at 11:06, Bertrand Drouvot
> <bertranddrouvot.pg@gmail.com> wrote:
> >
> >
> > Does it sound ok to you to move with the above principal? (I'm +1 on it).
> >
> 
> Hi! I looked through this thread.

Thanks for looking at it!

> Looks like we are still awaiting a patch which stores more counters
> (n_dead_tup, ... etc) into relfilenode stats.

Yes.

> 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:

1. We'd increase the BufferDesc size and approaching the 64 bytes limit (cache
line size) that we don't want to exceed (see comment above BufferDesc definition)
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
4. 3. seems to indicate that's not the right place

Then I think 1. and 2. are not worth it given 3. and 4.

There is probably other cons too though.

Regards,

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