Re: pg_buffercache: Add per-relation summary stats

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Khoa Nguyen <kdnguyen9(dot)oss(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-09 20:05:11
Message-ID: CA+TgmobD9zBt=UPbkM4kuEKw8OhQRN-tVKTwKkXUZfH-J0_8uQ@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

--
Robert Haas
EDB: http://www.enterprisedb.com

In response to

Browse pgsql-hackers by date

  From Date Subject
Previous Message Alexander Korotkov 2026-07-09 19:52:20 Re: SQL/JSON json_table plan clause