pg.ddx.io pgsql-hackers@postgresql.org mailing list archivehelp / color / mirror / Atom feed
From: 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: Wed, 2 Sep 2026 11:27:52 +0200
Message-ID: <11d0df16-94b8-4223-87f7-2e84084a28af@gmail.com> (raw)
In-Reply-To: <CADu+CpSyR3fnHGwTRAbULyBtxPZbkR2Y41Dd36ombAUwG4TT3g@mail.gmail.com>
References: <CA+K2RumP33Cpj--88E+rNADa8fzSBBiav=rvzyaMM=sYNaOkfA@mail.gmail.com>
<CAKZiRmzs99+q55pgBJ0-RHxL-z=ZRD-22cGR2w9jscOyxY-vfA@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>
>>> 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
view thread (36+ messages) latest in thread
Message-ID: <11d0df16-94b8-4223-87f7-2e84084a28af@gmail.com> Permalink: ../11d0df16-94b8-4223-87f7-2e84084a28af@gmail.com/ Also on: postgresql.org/message-id/11d0df16-94b8-4223-87f7-2e84084a28af@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: <11d0df16-94b8-4223-87f7-2e84084a28af@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 DDX for PostgreSQL; see mirroring instructions for how to clone and mirror all data and code used for this inbox