| 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-02 09:27:52 |
| Message-ID: | 11d0df16-94b8-4223-87f7-2e84084a28af@gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
>>> I chose to keep an accurate running count of the memory footprint per
>>> backend by tracking both the sizeof(Vfd) and the exact filename string
>>> lengths.
>>>
>>> We add the string length to the total footprint when a file is opened,
>> and
>>> subtract it when the VFD is freed (i suppose this is not "Too much" of a
>>> work done, although it's done in a bit hot place); v5 of the patch is
>>> attached.
>> Better use GetMemoryChunkSpace() instead of using strlen() + 1, to get
>> the true allocation size.
>>
> That wouldn't work because filename is malloc'd and not palloc'd, which is
> 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.
--
David Geier
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Matthias van de Meent | 2026-09-02 10:10:47 | Re: Reducing relcache memory usage: deduping index shapes |
| Previous Message | Peter Smith | 2026-09-02 09:19:19 | Re: PSQL schema "describe" \dn is not escaping quotes |