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

In response to

Responses

Browse pgsql-hackers by date

  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