Re: Add pg_stat_vfdcache view for VFD cache statistics

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-09-07 09:32:57
Message-ID: CADu+CpSY57xpQsGr1CAESUHxGv_Y3_aABmkHC-Gh9GpEG3tpPw@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Sep 7, 2026 at 8:49 AM David Geier <geidav(dot)pg(at)gmail(dot)com> wrote:

> >>> what GetMemoryChunkSpace() works on IIUC.
> >>> Am i correct here?
> >> That's interesting an interesting realization. You're right that we
> >> cannot use GetMemoryChunkSpace() in that case.
> >>
> >> However, I'm wondering if the better approach wouldn't be to change fd.c
> >> to use a long-lived memory context. Then all bookkeeping would happen
> >> automatically and the memory size could simply be reported via existing
> >> memory context stats infrastructure.
> >>
> >> Not entirely sure though if there's some roadblock when switching to a
> >> memory context.
> > I don't see any issue with this either. However, the only benefit we
> would
> > gain is using existing infrastructure but only for backend vfd cache
> memory
> > (i.e cache_bytes).
> > Everything else stays the same (counters, cluster-wide memory);
> therefore,
> > if there's no other benefit to replacing with memory contexts, maybe it's
> > not worth it.
>
> The biggest benefit in my view is consistency with the rest of PostgreSQL.
> That is from a usage point of view as well as from a coding point of view.
> If you want, I can give that a try and share a patch with you if
> successful.
>
Yes of course, I’d be happy to take a look.

Regards,
Ayoub

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Филиппов Степан 2026-09-07 09:36:14 Re: [PATCH] Fix timeline history after recovery stops on an ancestor
Previous Message Jakub Wartak 2026-09-07 09:15:25 Re: enhancing pg_basebackup speeds up to ~23Gbps (small fixes + io_uring/Direct I/O)