| 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
| 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) |