agora inbox for pgsql-hackers@postgresql.org
help / color / mirror / Atom feedFrom: David Geier <geidav.pg@gmail.com>
To: Ayoub Kazar <kazarayoub2004@gmail.com>
Cc: KAZAR Ayoub <ma_kazar@esi.dz>
Cc: Tomas Vondra <tomas@vondra.me>
Cc: Jakub Wartak <jakub.wartak@enterprisedb.com>
Cc: Pg Hackers <pgsql-hackers@postgresql.org>
Subject: Re: Add pg_stat_vfdcache view for VFD cache statistics
Date: Mon, 7 Sep 2026 08:49:32 +0200
Message-ID: <3b394e5f-ac4e-446c-b422-92be2b984722@gmail.com> (raw)
In-Reply-To: <CADu+CpT=ZYM2+zP41Dt8PRo=pmoY7TfN5Yc-Npp2T9tPOAvzbA@mail.gmail.com>
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>
>>> 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
view thread (36+ messages) latest in thread
Message-ID: <3b394e5f-ac4e-446c-b422-92be2b984722@gmail.com>
Permalink: ../3b394e5f-ac4e-446c-b422-92be2b984722@gmail.com/
Also on: postgresql.org/message-id/3b394e5f-ac4e-446c-b422-92be2b984722@gmail.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: pgsql-hackers@postgresql.org
Cc: geidav.pg@gmail.com, kazarayoub2004@gmail.com, ma_kazar@esi.dz, tomas@vondra.me, jakub.wartak@enterprisedb.com
Subject: Re: Add pg_stat_vfdcache view for VFD cache statistics
In-Reply-To: <3b394e5f-ac4e-446c-b422-92be2b984722@gmail.com>
* 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