Re: Add pg_stat_vfdcache view for VFD cache statistics

From: David Geier <geidav(dot)pg(at)gmail(dot)com>
To: Ayoub Kazar <kazarayoub2004(at)gmail(dot)com>
Cc: KAZAR Ayoub <ma_kazar(at)esi(dot)dz>, Tomas Vondra <tomas(at)vondra(dot)me>, Jakub Wartak <jakub(dot)wartak(at)enterprisedb(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Add pg_stat_vfdcache view for VFD cache statistics
Date: 2026-09-07 06:49:32
Message-ID: 3b394e5f-ac4e-446c-b422-92be2b984722@gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Hannu Krosing 2026-09-07 06:51:42 Re: Direct TOAST v2, faster, smaller and no migration needed
Previous Message Chao Li 2026-09-07 06:40:40 Re: Introducing find_all_inheritors_ordered()