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
