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