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
