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.
Done.
>> 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:
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.
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.
