Message-ID: <c94c385a-cdf6-44c5-9768-b8c47ab75868@gmail.com>
Date: Fri, 1 May 2026 15:56:32 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Add pg_stat_vfdcache view for VFD cache statistics
To: KAZAR Ayoub <ma_kazar@esi.dz>
Cc: Tomas Vondra <tomas@vondra.me>,
 Jakub Wartak <jakub.wartak@enterprisedb.com>,
 Pg Hackers <pgsql-hackers@postgresql.org>
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>
Content-Language: en-US
From: David Geier <geidav.pg@gmail.com>
In-Reply-To: 
 <CA+K2Ruk55=2fBftAMg3Y=--+6uSNF05UVmu8w8S8FdJ+ektQcg@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Archived-At: 
 <https://www.postgresql.org/message-id/c94c385a-cdf6-44c5-9768-b8c47ab75868%40gmail.com>
Precedence: bulk

On 29.04.2026 15:45, KAZAR Ayoub wrote:
>>>> The global cache stats is going to be virtually free (at least the
>>>> hits/misses, I'm not sure about the number of entries and bytes), and
>>>> it's obviously useful for tuning the max_files_per_process GUC. I'd even
>>>> contemplate getting this into PG19, maybe.
>>
>> The number of used entries already exists, see nfile in fd.c.
>>
> Would one want the number of all entries (i.e SizeVfdCache see fd.c) or the
> number of used entries (i.e entries with fds in use, which is nfile) ? I
> thought of the first, that's what 0002 patch contains for the moment.

I thought we would expose both. That way we can assess in the field if
being able to shrink the cache would be useful.

>> Including the total cache size would also be virtually free if we don't
>> iterate over all VFDs each time, but update the size as we go. That
>> would have to happen when resizing the cache and when populating /
>> freeing a cache entry because extra memory is allocated / freed for
>> Vfd::fileName.
>>
> Is it a big deal if we miss some bytes of filename globally ?

It's not just some bytes. sizeof(struct vfd) is 56 bytes and fileName
looks typically something like:

- base/5/1249
- pg_wal/000000010000000000000001
- pg_wal/archive_status/000000010000000000000001.ready
- pg_xact/0000
- pg_multixact/offsets/0000

File names can vary in length between 10 - 55 bytes, give or take. Most
files will be table and index segments and WAL files. We could maybe add
a fixed constant as "assumed average file name length" but I'm worried
that might end up being quite wrong.

--
David Geier