Message-ID: <3b394e5f-ac4e-446c-b422-92be2b984722@gmail.com>
Date: Mon, 7 Sep 2026 08:49:32 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Add pg_stat_vfdcache view for VFD cache statistics
To: Ayoub Kazar <kazarayoub2004@gmail.com>
Cc: KAZAR Ayoub <ma_kazar@esi.dz>, Tomas Vondra <tomas@vondra.me>,
 Jakub Wartak <jakub.wartak@enterprisedb.com>,
 Pg Hackers <pgsql-hackers@postgresql.org>
References: 
 <CA+K2RumP33Cpj--88E+rNADa8fzSBBiav=rvzyaMM=sYNaOkfA@mail.gmail.com>
 <c85907b2-1e91-47e3-82dc-dafda295ded4@gmail.com>
 <CA+K2Ru=WXpG1Sfx=_DQVn7ENZz6C_j-HxVJ1TmkEKowLVQcYwg@mail.gmail.com>
 <d305fd37-346b-4512-808e-5dd7968eb569@gmail.com>
 <CA+K2RuncGCW55b-XUe8gJGwdMSOgTFKG-uSCgbVDZ+HewiT5EQ@mail.gmail.com>
 <CA+K2RumDZ05pru3-YSZxe3Y==vO0hsahiweyvJw6QsjuGR5WsA@mail.gmail.com>
 <42776281-3603-4161-b47d-d4ffd2029e8c@vondra.me>
 <CA+K2RumSp-kTw_YHXs_qN_RLt6cWfFR=LMq9coLgu8eyGydpHQ@mail.gmail.com>
 <02cfc5e7-e152-4d2d-8b4b-e899d9901ed5@gmail.com>
 <CA+K2Ruk55=2fBftAMg3Y=--+6uSNF05UVmu8w8S8FdJ+ektQcg@mail.gmail.com>
 <c94c385a-cdf6-44c5-9768-b8c47ab75868@gmail.com>
 <CADu+CpTwQXRdoKVSnoVRLp5m0UbA_cAU6s+_Og5=hCwKp0JR2Q@mail.gmail.com>
 <52677fc8-f57d-48c2-9415-6beb3ea6fa01@gmail.com>
 <CADu+CpSyR3fnHGwTRAbULyBtxPZbkR2Y41Dd36ombAUwG4TT3g@mail.gmail.com>
 <11d0df16-94b8-4223-87f7-2e84084a28af@gmail.com>
 <CADu+CpT=ZYM2+zP41Dt8PRo=pmoY7TfN5Yc-Npp2T9tPOAvzbA@mail.gmail.com>
Content-Language: en-US
From: David Geier <geidav.pg@gmail.com>
In-Reply-To: 
 <CADu+CpT=ZYM2+zP41Dt8PRo=pmoY7TfN5Yc-Npp2T9tPOAvzbA@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
 <https://www.postgresql.org/message-id/3b394e5f-ac4e-446c-b422-92be2b984722%40gmail.com>
Precedence: bulk

>>> what GetMemoryChunkSpace() works on IIUC.
>>> Am i correct here?
>> That's interesting an interesting realization. You're right that we
>> cannot use GetMemoryChunkSpace() in that case.
>>
>> However, I'm wondering if the better approach wouldn't be to change fd.c
>> to use a long-lived memory context. Then all bookkeeping would happen
>> automatically and the memory size could simply be reported via existing
>> memory context stats infrastructure.
>>
>> Not entirely sure though if there's some roadblock when switching to a
>> memory context.
> I don't see any issue with this either. However, the only benefit we would
> gain is using existing infrastructure but only for backend vfd cache memory
> (i.e cache_bytes).
> Everything else stays the same (counters, cluster-wide memory); therefore,
> if there's no other benefit to replacing with memory contexts, maybe it's
> not worth it.

The biggest benefit in my view is consistency with the rest of PostgreSQL.
That is from a usage point of view as well as from a coding point of view.
If you want, I can give that a try and share a patch with you if successful.

--
David Geier