Re: pg_buffercache: Add per-relation summary stats

From: Khoa Nguyen <kdnguyen9(dot)oss(at)gmail(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Tomas Vondra <tomas(at)vondra(dot)me>, Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com>, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, Lukas Fittl <lukas(at)fittl(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Paul A Jungwirth <pj(at)illuminatedcomputing(dot)com>, Khoa Nguyen <khoaduynguyen(at)gmail(dot)com>
Subject: Re: pg_buffercache: Add per-relation summary stats
Date: 2026-07-14 20:53:45
Message-ID: CAONt3B0VnKVaM=Ka-hm5+y=APGrnn=0985Ldp2wZLxLxzkaeQw@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Given that going beyond the reasonable work_mem is pathological and
rare, I can see why documenting it is a simpler and better choice.
Attached is v4 with memory uncapped with documentation. I kept the
usagecount_total from v3. Happy to keep iterating if there's more to
address.

On Thu, Jul 9, 2026 at 1:05 PM Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>
> On Thu, Jul 9, 2026 at 2:58 PM Khoa Nguyen <kdnguyen9(dot)oss(at)gmail(dot)com> wrote:
> > I think erroring out when the
> > estimated hash size exceeds work_mem is sufficient. We can rely on
> > the DBA’s call to increase this session’s work_mem for this particular
> > query to go through without affecting all backends.
>
> I am -1 on an error in that case. I would just document how much
> memory the function can potentially use.
>
Given that going beyond the reasonable work_mem is pathological and
rare, I can see why documenting it is a simpler and better choice.
Attached is v4 with memory uncapped and documentation. I kept the
usagecount_total from v3. Let me know if anything else needs to be
addressed.

Thanks,
-Khoa

Attachment Content-Type Size
v4-0001-pg_buffercache-Add-pg_buffercache_relations-funct.patch application/octet-stream 16.4 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Masahiko Sawada 2026-07-14 21:02:39 Re: Fix "unexpected logical decoding status change" error; from concurrent logical decoding activation
Previous Message Tristan Partin 2026-07-14 20:50:17 Re: Grab bag of smaller OpenSSL fixups