| From: | Ayoub Kazar <kazarayoub2004(at)gmail(dot)com> |
|---|---|
| To: | David Geier <geidav(dot)pg(at)gmail(dot)com> |
| Cc: | KAZAR Ayoub <ma_kazar(at)esi(dot)dz>, Tomas Vondra <tomas(at)vondra(dot)me>, Jakub Wartak <jakub(dot)wartak(at)enterprisedb(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Add pg_stat_vfdcache view for VFD cache statistics |
| Date: | 2026-07-12 22:44:06 |
| Message-ID: | CADu+CpTwQXRdoKVSnoVRLp5m0UbA_cAU6s+_Og5=hCwKp0JR2Q@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hello everyone,
This is Ayoub again, I've just changed my email address.
On Sun, Jul 12, 2026 at 11:57 PM David Geier <geidav(dot)pg(at)gmail(dot)com> wrote:
> 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:
>
> - 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.
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.
>
>
> --
> David Geier
>
> Regards,
Ayoub KAZAR
| Attachment | Content-Type | Size |
|---|---|---|
| v5-0001-Add-pg_stat_vfdcache-view-for-VFD-cache-statistics.patch | text/x-patch | 24.8 KB |
| v5-0002-Add-VFD-cache-footprint-metrics-to-pg_stat_vfdcache.patch | text/x-patch | 17.6 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andrei Lepikhov | 2026-07-12 23:28:55 | Re: RFC: Logging plan of the running query |
| Previous Message | Daniel Gustafsson | 2026-07-12 20:59:37 | Re: allow spread checkpoints when changing checksums online |